Delivery and pipeline health
What became of every outgoing message, what each delivery state does and does not prove, and how incidents are raised.
The Delivery page follows messages after they leave eCEBS: the receipt sent back to the reporter, the alerts sent to recipients, and the health checks of each part of the pipeline. It answers the question the logs cannot — did the message actually get out?
What each state claims
Every send is recorded with one state, chosen for exactly what is known — never more.
| State | What it means |
|---|---|
| Accepted by DHIS2 | DHIS2 took the request. Nothing more is known yet. |
| Rejected by DHIS2 | DHIS2 refused it outright, with a reason. |
| Accepted by gateway | A later check saw DHIS2 hand it to the SMS gateway. |
| Failed at gateway | A later check saw the gateway report an error. |
| Delivered | A phone confirmed it. Not possible today — see below. |
| Fate unknown | It was accepted, but what happened next could never be established. |
| Invalid number | Never sent — the number was malformed. |
Accepted is not received
This deployment receives no delivery receipts from the telco, so no message can be confirmed as received by a phone. The most that can be proven is accepted by gateway. A message whose fate is unknown is never counted as a success — that habit is how a month-long outage once looked like perfect health.
The page, top to bottom
- Headline numbers — sends, accepted by a layer, reached the gateway, failed, and fate unknown, for the chosen window. They are kept separate on purpose; there is no single success rate.
- By delivery state — one bar per state.
- Sends over time — accepted, fate unknown and failed, stacked, so a rising band of red or amber is visible at a glance.
- Pipeline health — each part of the pipeline eCEBS can observe (SMS via DHIS2, DHIS2 messages, DHIS2 events, the inbound gateway) with its current state and a strip of recent checks. The relay, the SMS gateway and the telco sit past DHIS2 and are not monitored here.
- Incidents — every period a part of the pipeline was degraded or down, with when it started, when it ended, and how long it lasted.
Incidents and the banner
The backend checks each part of the pipeline every few minutes. When one turns bad, an incident is opened, dated from the first bad check rather than from when it was noticed. While any incident is open, a coloured banner appears at the top of every portal page for every role, so an outage is seen without anyone going to look for it. Unknown means too few checks to judge — it is shown, never treated as healthy.
Who sees what
Every role sees the numbers, the chart, pipeline health and incidents. The delivery records and invalid numbers list contain phone numbers, so they are shown to analysts, configurators and administrators only; phone numbers stay masked until revealed.
From any message in the logs explorer, View deliveries opens this page filtered to that one message, showing every send it produced.
Invalid numbers
Numbers that were never sent to are listed exactly as supplied, with how often they occurred. They almost always come from reporter records in DHIS2 — fixing them at the source is the only lasting fix.