Logs explorer
Finding a message, reading its pipeline, and following traffic as it arrives.
The explorer lists every message the system has handled, newest first. It is the tool for answering "what happened to this message?" and "why are these messages failing?".
The table
| Column | What it shows |
|---|---|
| Time | When the message arrived |
| Sender | The phone number it came from |
| Code | The signal code carried in the message |
| Pipeline | The five stages, and how far the message got |
| Outcome | The overall result |
The pipeline column is the one to read first. It shows the five stages at a glance, so a row that stops at Reporter is telling you the sender was not registered without your having to open it.
Saved views
Four views cover the common questions:
- All messages — everything, newest first.
- Unregistered senders — messages from numbers the system does not recognise.
- Failed deliveries — replies the gateway could not deliver.
- DHIS2 failures — messages that parsed correctly but could not be written as events.
Each is a starting point rather than a limit; add filters on top of any of them.
Filtering
Search matches the message text, the phone number, and the reference number. Beyond that, filters can be added on individual fields — code, EBS type, phone, reference number — and combined, along with a time range.
Live tail
Turning on Live follows traffic as it arrives, which is what you want in the minutes after publishing a flow. New messages are announced as they land. Turn it off before settling in to investigate, so rows stop moving under you.
Inspecting one message
Selecting a row opens the detail drawer with the full message, each stage and its result, and the identifiers needed to follow the message elsewhere. The message ID can be copied for referencing in a ticket, and the request can be copied as a cURL command to reproduce it outside the portal.
A practical order of investigation
- Filter to the failures, using a saved view or the outcome.
- Read the pipeline column to find the stage they stop at. Failures that share a stage usually share a cause.
- Open one and read its detail in full.
- Act on the stage. Grammar failures point at the flow's grammar or its codes; Reporter failures at registration; Event failures at DHIS2 or the mapping; Reply failures at the gateway.
When many messages fail at once
Check whether they share a stage, and whether they started at a particular time. A sudden cliff at the Event stage generally means DHIS2 rather than a configuration change; a cliff at Grammar generally follows a flow being published or edited. The health overview shows both shapes more clearly than the table does.