Channel health dashboard: when do you notice WhatsApp has dropped?

Tuesday, 9:40 in the morning. A two-person support desk at an online retailer usually has a busy first hour: between nine and ten, roughly thirty WhatsApp messages land, mostly shipping questions and returns. That morning, only four arrived by eleven. Nobody flagged it. A quiet day, someone said. In the afternoon a customer wrote in through Instagram: "I've been messaging you on WhatsApp since yesterday and nobody replies." The connection had dropped at 18:20 the previous evening, and every message sent after that had never reached the inbox. There was no error on any screen. There was only a gap, and a gap wakes nobody up.

This article walks through how to make channel outages visible, in order: what actually breaks when a channel "goes down", why an outage can run for hours unnoticed, which symptoms point to a connection problem, what a health check does and does not verify, what webhook logs settle, how rate limits quietly throttle you, where automatic reconnection stops helping, how to pick an alert threshold per channel, the order a team should work through during an incident, and how to clear the backlog once the channel is back.

What actually breaks when a channel "goes down"?

The sentence "WhatsApp is down" hides at least four different faults, which is exactly why it slows down the fix. The first is an authorisation failure: the access token has expired or been revoked and the system can no longer talk to the platform. The second is a webhook break; the platform keeps delivering your messages, but your endpoint stops acknowledging them, so they never arrive. The third is a rate limit: the connection is fine, the sending is refused. The fourth is an account-level restriction, where quality has dropped, templates have been rejected, or the number has been temporarily limited.

These four look identical from the outside and get repaired in four different places. An expired token is fixed by reconnecting, a webhook break on your own infrastructure, a rate limit by rescheduling sends, and an account restriction only through the platform. If you run a business number, reading the fault table requires knowing how that number was provisioned; it is worth understanding what the WhatsApp Business API actually commits you to before diagnosing anything on it.

There is a fifth class, and it is the one most often ignored: a personal line connected by QR code. That line lives on a phone. When the phone runs out of battery, goes into airplane mode, or someone signs out of the app, the session drops. Technically nothing has broken. Nobody was simply looking.

Why does an outage go unnoticed for hours?

Because the symptom is not an error, it is an absence. Most software failures announce themselves: a red banner, a failed request, a queue backing up. A channel outage does the opposite, it makes the screen quieter, and silence triggers no reflex in a support team. If anything, it feels like relief.

The second reason is that inbound volume genuinely fluctuates. An inbox that takes thirty messages on Thursday morning may take eight on Friday afternoon, and that is normal. Used to the swing, the team attributes any drop to seasonality. If you have never written down what a channel's normal rhythm looks like, you cannot notice it breaking. Teams that have already decided which channel carries what weight in which market spot the anomaly faster, because they know the distribution they expect.

The third reason is the shift handover. A channel that went quiet in the evening is simply quiet to whoever opens the inbox in the morning; their reference point is today's start, not last night. Outages are most likely to begin outside working hours, and those are precisely the hardest ones to catch.

Which symptoms point to a connection problem?

There are five signals, and none of them proves anything alone; they are useful read together. The first is a volume drop measured against the channel's own history, not the inbox total. The second is one-way traffic: outbound messages leave, nothing comes back. That is the signature of a broken webhook, because sending and receiving travel different paths and one can work without the other.

The third is delivery status stalling. If messages sit at "sent" and never move to "delivered", the problem is on the far side. The fourth, and the strongest, is channel migration. A customer who gets no answer does not disappear, they knock on another door. A message arriving by email or Instagram that begins "I wrote to you on WhatsApp and nobody replied" is, functionally, an incident report. If you sell into CIS markets, that migration often lands as an inbound message on Telegram, where it is again spotted only by accident.

The fifth is automated behaviour falling silent. If you run an out-of-hours auto-reply, every message that arrives while you are closed produces one. A night with zero auto-replies means a night with zero inbound messages, which is a sharper signal than a volume drop because it distinguishes none from few.

What does a health check verify, and what does it miss?

The channel health dashboard in the unified inbox polls three things on a schedule: whether the connection is alive, whether the webhook endpoint is responding, and how long it has been since the last activity on that channel. Rate limit tracking and webhook logs sit on the same screen, so you are not opening three tools to work out which fault class you are in. Its job is not to prevent outages but to make them visible, and that distinction matters, because no dashboard can stop a failure on the platform's side.

What it does not verify should be equally clear. A live connection does not mean the message reached the customer; that comes from delivery status. An open channel does not mean your content was accepted either; template rejection is a separate matter. The health dashboard tells you whether the pipe is blocked. It says nothing about the quality of the water going through it.

The dashboard earns its keep at the moment nobody is looking at it, which is why it belongs wired as a notification source rather than as a tab. A screen someone is supposed to check during the day will, by definition, never catch a connection that dropped at two in the morning.

What question do webhook logs settle?

Exactly one, and it ends the argument: did the platform send it, and did we receive it? There are three possible answers, and each belongs to a different team. If the platform never sent anything, the fault is on the account side: permissions, a restriction, or a mismatched number. If it sent and your endpoint never returned a success, the fault is in your infrastructure. If you received it but no conversation opened, the fault is in processing.

Without logs there is no way to separate the three, and teams that cannot separate them spend hours searching the wrong layer. Logs also give you the exact start time of the outage, which is the one input you need to work out how many customers were affected.

How do rate limits quietly throttle you?

A rate limit differs from an outage because the channel is up. The connection reads as healthy, the dashboard is green, and yet some messages never leave. The usual cause is broadcast sends and one-to-one replies drawing on the same quota. If a campaign starting at eleven consumes most of the allowance, the replies your agents write in the afternoon queue behind it. The team calls this "the system is slow"; the system is not slow, it is waiting in line. When you plan compliant bulk messaging that will not get your number blocked, budgeting for shared quota is the simplest way to avoid locking your own support channel on campaign day.

The second source of throttling sits on the template side. A rejected or suspended template silently stops every automated send attached to it. In an order-notification flow this can run for days unnoticed, because customers do not say "I never got the notification", they just call. Knowing how to write a template that does not get rejected reduces this class of incident at the source.

Where does automatic reconnection stop helping?

Automatic reconnection closes most transient faults before a human sees them: brief network drops, a few minutes of instability on the platform side, delayed session refreshes. Without it a team gets pulled in several times a day for nothing, and alert inflation is the main reason real alerts stop being taken seriously.

The class it cannot fix is well defined and needs a person: a revoked token, an account-level restriction, a dropped QR session, a changed webhook address. In those cases retrying can continue indefinitely and nothing improves. So the rule is simple. Put a ceiling on retry count and retry duration, and when that ceiling is crossed, have the system stop retrying and tell a human instead. "Still trying" is not a resolved state.

What threshold should trigger an alert on each channel?

Tie the threshold to duration of silence rather than message volume. A volume threshold produces false alarms on campaign days and public holidays; a silence window can be tuned to each channel's rhythm. Saved view alerts do this directly: you store a filter combination you already use as a view, attach a threshold, and get a notification when it is crossed. Because the alert runs against the view's own conditions, a rule like "tell me if unanswered WhatsApp conversations pass five" can be set per channel rather than across the whole inbox.

Channel	Normal rhythm (example)	Silence threshold	First place to look
WhatsApp Business API	Ten to thirty messages per working hour	Ninety minutes with nothing inbound	Webhook log and delivery status
WhatsApp personal line (QR)	Irregular through the day but never zero	Three hours with nothing inbound	Session state and the paired phone
Instagram and Messenger	Low and uneven outside campaigns	One full business day with nothing inbound	Page authorisation
Email	Heavy in the morning, steady all day	Four hours with nothing inbound	Mailbox connection and the spam folder
SMS	Only moves when a reply comes in	Send failure rate at twice the normal level	Carrier report and the outbound queue

The values above are illustrative. Derive your own rhythm from two weeks of history and tighten the thresholds against it. Setting a window too tight is worse than setting it too wide, because a team that gets false alarms often will eventually ignore the real one.

The SMS row follows a different logic, because you are not waiting for inbound traffic there; what you measure is send success. The same distinction applies to email, and the two fail in different ways, so settling which of the two suits which kind of message before you set a threshold cuts false alarms directly.

In what order should the team work an incident?

Most of the time lost after an alert goes into deciding who does what. That is why the sequence needs to be written down in advance, with each step tied to a single question. The five steps below cover most teams: the first three are technical, the last two are customer-facing.

Step	Question asked	If the answer is no
1	Is the connection alive?	Trigger reconnection manually and refresh the token
2	Is the platform still sending?	Check account status and restrictions on the platform side
3	Are we acknowledging receipt?	Check the webhook address and your server response
4	Is another door open to customers?	Announce the fallback channel and update the away message
5	Are the affected conversations listed?	Tag the outage window and assign an owner

Step four is the one most often skipped. Leaving customers an open door while the channel is down cuts the cost of the outage directly. That door can be the chat widget on your site or a short notification message, but what matters is that the alternative was set up and tested before the incident. Standing up a new channel mid-outage doubles the failure.

Which alternative makes sense depends on where your customers already are. Teams selling into CIS markets often keep a second messaging line warm for exactly this reason, and Viber still carries real weight there, which makes it a credible fallback rather than an improvised one.

If you run a mobile app you have one more route: an in-app message or a push notification carries the outage notice without touching the messaging platform at all. Treating mobile as a channel in its own right pays off precisely in moments like this, because it depends on a different provider and is unlikely to fail at the same time.

Step five draws the boundary of the incident. Tagging every conversation inside the outage window gives you both the callback list and a way to keep your response-time metric honest. Without it, one bad night makes your monthly average look meaningless.

How do you clear the backlog once the channel is back?

When the connection returns, messages arrive in a single wave, and that creates a second problem: hundreds of conversations open at once, all equally late, so none of them looks urgent. The only approach that works is to prioritise by topic rather than by delay. Orders and payments first, general enquiries after. With assignment rules and SLA targets configured, you can set a separate target for conversations carrying the outage tag and distribute the load accordingly.

The second question is how the late reply is written. "Sorry for the delay due to high volume" tells the customer nothing; saying there was a technical outage and their message was not lost lands better. Because the customer's history sits next to the conversation, a late reply can open with context rather than an apology, which is far more effective. To track the accounts hit hardest afterwards, it is worth seeing how a customer health score flags an account at risk; the aftermath of an outage shows up there for weeks.

The third step sits on the sales side and is usually forgotten. Some of the people who wrote during the outage were not asking for support, they were ready to buy. Those conversations need a separate pass, because a support question can wait and a warm request cannot. The same logic as a deal health score that shows which opportunity has stalled applies here: an opportunity that went quiet is not an opportunity that closed.

To turn all of this into a routine rather than a scramble, start a free Rocketly account and bring your channels into one inbox first.

FAQ

How quickly should an outage realistically be detected?

Thirty to ninety minutes during working hours is achievable for most teams; outside working hours, the goal is that whoever opens the inbox next knows the state immediately. The number itself matters less than having it written down per channel and wired to an alert.

If reconnection is automatic, do I still need alerts?

Yes. Automatic recovery closes transient faults, not permanent ones. Attach the alert to the "retry ceiling exceeded" state rather than to the outage itself and you catch real failures without drowning in notifications.

Why does a QR-connected personal line drop more often?

Because it depends on a physical device you do not control. A phone powering off, someone signing out of the app, or a long stretch without network will end the session. Moving critical flows onto a business number rather than a personal line reduces that exposure.

Do messages sent during an outage arrive afterwards?

It depends on the channel. Some platforms retry delivery for a defined window, and everything lands at once when the connection returns; on others, once that window closes the message is gone. Shortening the outage is a more reliable strategy than relying on recovery.