Skip to main content

​
Read the channel health widget

The Channels section on Home renders one tile per enabled channel, each carrying a Healthy / Degraded / Failing pill, an average delivery-latency figure, a delivery rate, and (when something failed in the window) a confirmed-failure count with an Investigate link. This guide explains exactly which signals feed those tiles, how to read a red tile that the rest of the platform shows as operational, and the recovery sequence to run when one goes bad.

​
1. What each tile measures

Each tile is a rolling-window read of your own outbound traffic on that channel. It is not a platform infrastructure probe and not a forecast. How the verdict is computed. Orbit counts the sends on a channel that reached a terminal outcome (delivered, or confirmed failed) over the rolling window and looks at the share that confirmed-failed:
  • Below 5% confirmed failures: Healthy.
  • 5% up to below 20%: Degraded.
  • 20% or more: Failing.
  • Fewer than 10 terminal sends in the window: no verdict is applied, so a low-volume channel is never judged on a handful of messages.
Sends that were accepted but never produced a receipt count as unknown, not as failures: a silent receipt backlog cannot flip a tile to Failing on its own, though those sends do not count toward the delivery rate until they resolve. What does not feed the tile. Opt-out rate, complaint rate, and spend are not inputs to the health verdict; they live on the compliance and analytics surfaces. Platform infrastructure uptime is not an input either: the “Platform status” link next to the section header points at status.orbit.devotel.io, which runs synthetic uptime probes and answers a different question (“is the platform reachable right now?”) than the tiles (“how did your sends do over the window?“).

​
2. A trailing signal, not a live one, not a forecast

The default window is the rolling 24 hours (the page polls the underlying endpoint every 30 seconds, but each poll re-reads that 24 h window). Two consequences follow, and they are the reason a tile can disagree with everything else you see:
  • A tile lags a recovery. An outage early in the window keeps its failures inside the window for hours after the channel is fixed, so a tile can read Failing while new sends are delivering normally. The one exception is the recovery rule: once your most recent traffic shows at least 5 confirmed deliveries with a recent confirmed-failure rate below the 5% degraded floor, the tile clears back to Healthy without waiting for the old failures to age out of the window.
  • A tile lags a new failure the other way. A channel that started failing minutes ago still averages its failures against the whole window, and the 10-send volume floor applies, so a brand-new problem may show Healthy until enough terminal outcomes accumulate.
Treat the tile as “how did this channel’s traffic do over the last day”, and treat the platform status page plus the live gateway strip on Messages → SMS as “what is happening right now”. (The SMS workspace strip reads the same delivery outcomes but applies an extra delivery-rate floor of its own, so for SMS it can show a stricter verdict than the Home tile; see SMS overview, metrics console.)

​
3. Reading a red tile while the rest of the dashboard says Operational

Because the tiles measure your traffic’s outcomes, a red tile with a green platform is usually a tenant-side delivery problem: bad or unreachable destinations, carrier content or registration rejections, exhausted credits, or a compliance gate blocking sends. The platform accepting your sends and your sends being delivered are two different facts. Read the tile in this order:
  1. Failed count first. “312 / 1,204” tells you the blast radius before anything else.
  2. The reason line under the pill names the dominant cause class (failure-rate driven vs. latency driven).
  3. Investigate deep-links into the channel’s message hub with the failed view pre-filtered, so you land on the receipts that explain the verdict instead of the generic hub.
If the reason is latency rather than failures (the tile stays Healthy/Degraded while the latency row reads high), the channel is congested rather than failing: sends are landing, slowly. The recovery table below separates the two cases.

​
4. Recovery: the tenant-owned repair path, time-boxed

The sequence operators actually run when a tile degrades, with the window in which each step bites. Every step is a control you own; none of them requires platform action. Channel-specific checks worth running at step 3:
  • SMS: campaign registration state, filtered or invalid destination numbers, and per-carrier rejection codes in the failed view.
  • WhatsApp: template approval status and recipient opt-in evidence for the audience you sent to.
  • Email: list hygiene (hard bounces and suppressions) and the sender domain’s recent reputation; a stale imported list is the classic cause of a red email tile on an otherwise healthy account.
  • Voice: destination reachability and your trunk/SIP configuration under Voice; re-test with a single call.
Pausing (step 2) stops new failures but does not delete the old ones: without a healthy re-test batch (step 7) the tile only clears as the incident ages out of the 24 h window.

​
5. The impact banner and the per-channel notice

Above the tile row sits a single impact banner: the worst severity across all channels, rendered as “All channels operational”, “Elevated delivery failures on …”, or “Delivery failing on …”, with the affected channel names. When impacted channels carried terminal traffic, the banner leads with the blast radius (“N failed deliveries across M messages”) before the per-status counts, so one glance answers “how bad, and where”. The banner and the tiles are two projections of the same read and cannot disagree: the banner is the headline (worst severity, affected names, failure totals), the tile is the drill-down (the reason line plus the Investigate link into the filtered failure view). One bad channel therefore reads as one banner naming it, not as five unexplained red tiles.

​
6. Where the data comes from

The widget, the Messages hub channel cards, and the per-channel breakdown on Reports all render one read: GET /api/v1/stats/channel-health?days=N, with N from 1 to 365 and a default of 1 (the rolling 24 h). The dashboard polls it every 30 seconds while you are signed in, stops polling on background tabs and expired sessions, and shares one cache entry across surfaces, so opening Messages from Home shows already-fetched data instead of a second request. Behaviour at the edges:
  • After a message send or a delivery receipt lands, the value refreshes within a poll cycle rather than at the next full recompute.
  • On a transient backend blip the section shows a contained error with a Retry (and the page-level warning banner lists it) instead of rendering a half-broken row.
  • A workspace with no channels configured yet shows a setup hint instead of tiles.
Because every figure on the tiles is also available from the endpoint, you can wire the same read into your own monitoring: poll /api/v1/stats/channel-health and alert on any channel’s status leaving operational, using the same thresholds this page documents.

​
See also