Failure notifications
A chat bot fails silently: visitors see an apologetic message and leave — nobody calls you. The Notifications tab fixes that: it emails the people you choose the moment the bot stops answering, and keeps the noise down with built-in anti-spam throttling.
What triggers an alert
Two problems are watched, and each is tracked separately:
| Problem | What it means |
|---|---|
| Daily message limit reached | The client's daily message budget is exhausted — every further visitor is turned away until the 24-hour window rolls over. See Limits & quotas. |
| AI provider request failed | The AI provider couldn't process requests — a wrong or expired API key, a provider outage, a misconfigured model or base URL. Visitors get the error message instead of answers. |
Setting it up
- Open your client → Notifications tab.
- In Failure alerts, keep Notify on failures ticked (it's the master switch — untick to keep your receiver list but send nothing).
- Choose the throttle: "At most one email per problem per" → Hour or Day (24 hours).
- Press Save.
- In Receivers, use Add receiver: a Name (e.g. "Jane at Support") and an Email, then press Add receiver. Up to 10 receivers; each row has a Remove button.
With no receivers, nothing is sent — adding at least yourself is part of the first bot checklist.
How the anti-spam throttling works
A broken bot fails every request with the same cause — you want one clear email, not five hundred. So alerts are throttled per problem:
- The first failure of a problem sends an email right away.
- Further failures of the same problem within your chosen window (hour or day) are counted, not emailed.
- When the window has passed and the problem occurs again, the next email goes out — and it includes the count: "N requests failed since the previous alert." No failure is ever hidden; it's just batched.
- The two problem types are throttled independently — a daily-limit alert never delays an AI-provider alert.
Choose Hour if you want to react fast (support team on duty), Day if one summary per day per problem is enough.
The "Recent problems" table
The bottom card shows what has been failing and when receivers last heard about it:
| Column | Meaning |
|---|---|
| Problem | Which of the two problems it is. |
| Counted since last alert | Failures suppressed inside the current throttle window — they'll be reported in the next email. |
| Last error | The most recent error text (e.g. the provider's message about an invalid key). |
| Last occurred | When the problem last happened. |
| Last alert sent | When receivers were last emailed — or "never". |
"No failures recorded. That's a good thing." means exactly that.
Emails require SMTP
Alert emails go out through the platform's email (SMTP) configuration:
- SaaS / hosted — already configured by your provider; nothing to do.
- Self-hosted — a platform admin must configure outgoing email under Admin → Notifications → SMTP (or via the
SMTP_*environment variables — see Self-hosting with Docker). Until then, alerts are recorded in Recent problems but no email leaves the server.
If alerts don't arrive
Check, in order: receivers exist → Notify on failures is ticked → you're not inside the throttle window (see Last alert sent) → spam folder → platform SMTP works (ask your admin). The full checklist lives in Troubleshooting.
Related
- What the visitor sees while the bot is failing: Limits & quotas and Languages (the "Error message" and "Limit reached" texts).
- Every individual failure, with its exact error: the activity log on the Statistics tab.