Alerts: know when a visitor is left waiting
A chat widget has one failure that costs you customers, and it is not downtime. It is somebody writing at 7pm, nobody being at the console, and the message sitting there until morning — while the visitor, who waited two minutes and left, has already found somebody else.
The alert exists for exactly that. It watches for a message that arrived when nobody was there, and emails your team about it. Alerts in the console.
What has to be true for an alert to be sent
All of these, in order:
- A customer wrote, in a conversation that is not closed.
- Nobody from your team was online in the console when the message landed.
- It is still unanswered after your waiting time — 3 minutes by default.
- Still nobody is online at that moment.
- It is inside your working hours, if you have set any.
The second one is the condition worth understanding, because it is what keeps this alert believable.
A message that arrives while somebody is at the console never produces an alert, even if it then goes unanswered for an hour. That is not the alert failing — a team that was there and did not reply is a staffing or workload problem, and an email would be telling them something they can already see in their own inbox. This alert answers one narrower question: did this message land in an empty room?
Two consequences follow:
- Somebody opening the console during the waiting time cancels the alert. They are exactly the person the email would have fetched, so fetching them is no longer necessary.
- A message older than an hour is never alerted about. That ceiling is the platform's, not a setting. It exists so a deploy or an outage cannot wake every owner about traffic they scrolled past long ago.
Who gets it
Everyone with the owner or admin role, at the address they sign in with. The settings page tells you how many people that is right now.
Operators never receive it, by design. The alert says "nobody is at the console" — it is a call to whoever decides who covers the evening, not to the person who is already off shift.
The email's subject is "Someone is waiting in your workspace chat", and its button opens that conversation directly in the console.
The four settings
| Setting | Default | Range |
|---|---|---|
| Alerts on or off | On | — |
| Wait before emailing | 3 minutes | 1 to 30 minutes |
| Quiet period after an email | 15 minutes | 5 minutes to 4 hours |
| Include the first line of the message | Off | — |
The page states the result of your own numbers back to you in a sentence — "a customer writing with nobody online reaches your team after 3 minutes, and at most once every 15" — which is easier to sanity-check than two number fields.
The waiting time is a balance between two bad outcomes. Too short and an operator who is mid-reply gets beaten to it by a robot; too long and the visitor has already gone. One minute is the floor because the check itself runs once a minute — asking for thirty seconds would not get the mail any sooner, it would only print a number that is not true.
The quiet period is the anti-spam rule, and it is the setting most worth leaving alone. It turns a busy hour with an empty console into one email carrying "Other conversations also waiting: 3" rather than four near-identical ones. Conversations that pile up in between are not lost — they ride along in the next one.
The preview puts the opening line of the customer's message into the email. Off by default, because it moves what a customer wrote into an inbox; on, it lets whoever reads the mail on their phone tell a pricing question from a fire without opening the console.
Turning alerts off stops the emails and nothing else. Waiting conversations still appear in the inbox, still show as needing a reply, and still count in the sidebar badge. The alert is a nudge, not the record.
Working hours
If your workspace has working hours set on the Widget page, no alert is sent outside them. The point of publishing hours is that nobody is expected to answer at 3am — an alert then would be a promise you never made.
If you have no working hours set, alerts are sent at any hour. That is the same logic read the other way: a workspace that never advertises being closed has no hour at which a waiting customer is acceptable. The Alerts page says which of the two you are on rather than making you go and check.
Why an alert did not arrive
In roughly the order these actually happen:
| What you saw | The likely reason |
|---|---|
| A conversation waited, no email | Somebody from the team was online when it arrived — that is the rule working, not failing |
| Nothing all evening | Outside your working hours |
| One email, several waiting conversations | The quiet period. They are listed in that one email as "also waiting" |
| Nothing after a busy morning's first alert | Still inside the quiet period — the next one waits it out |
| Nothing at all, ever | Alerts are switched off, or nobody in the workspace holds owner or admin |
| An alert about a conversation somebody already answered | The reply landed between the check and the send — a minute at most, and harmless |
If none of those fit, the fastest thing to check is the recipient list: the alert goes to owners and admins only, and a workspace whose second person is an operator has exactly one recipient.