Platform health and diagnostics
Platform → Health is the first place to look when something feels wrong with an instance: it combines a live end-to-end messaging test, vendor status feeds, and 24-hour tables of webhook deliveries, failed emails, cron jobs and the audit log on one screen, refreshed automatically. Start with the messaging health card, then use the tables below it to narrow down where in the pipeline a problem sits.
Messaging health card
At the top of the page, the messaging health card runs a synthetic check against a test target you configure — never a real customer number — across four steps:
| Step | What it confirms |
|---|---|
| Credentials present | Your Infobip API key (or the managed connection) is configured and readable. |
| Relay reachable | If you're on a bring-your-own key behind the Cloudflare relay, the relay itself responds. |
| Test send succeeds | A message can actually be dispatched through Infobip to your chosen test number. |
| Inbound message received | A reply sent back to your test sender arrives and is recorded as inbound. |
Each step shows one of pass, fail, warning, or not-tested, so a broken pipeline is diagnosable at a glance: credentials-pass-but-send-fail points at Infobip or the relay, while send-pass-but-inbound-fail points at your webhook registration on the Infobip side rather than your outbound sending. Set or change the test number and channel (WhatsApp or SMS) directly on the card, and re-run the test on demand — it also refreshes automatically every five minutes.
Service status cards
Below the messaging card, three status cards report vendor-side health:
- Infobip — polled periodically and shown with an indicator (operational, minor issue, outage, maintenance), a description, up to five affected components, and any active incidents, each linking out to status.infobip.com for detail.
- Cloudflare — the same indicator model, linking to cloudflarestatus.com. Relevant primarily if you run a bring-your-own Infobip key behind the Cloudflare relay.
- Meta — a set of deep links to Meta's own status pages for WhatsApp Business API, Graph API, Marketing API, and Messenger/Instagram, since Meta does not expose a polled feed the same way; check these manually if WhatsApp-specific symptoms appear.
These reflect the vendor's own incidents, not your instance's configuration — an outage shown here means check whether you're affected before assuming a local misconfiguration, and cross-reference against the messaging health card and your own webhook deliveries.
Metric tiles
A row of tiles summarises the last 24 hours: emails sent, failed and pending; webhooks sent and failed; messages and conversations. These are the numbers to watch after a deploy or configuration change — a sudden jump in failures with no corresponding rise in volume is the clearest signal something broke.
The four detail tabs
- Webhook deliveries — every outbound webhook delivery in the last 24 hours across all endpoints, with event name, status, HTTP response code, attempt count and timestamp. This is the aggregate view; drill into a specific endpoint's history and retry individual deliveries from Settings → Webhooks. See API and webhooks for how signing and retries work.
- Failed emails (DLQ) — the dead-letter queue of emails that failed to send, with message ID, status and timestamp, so you can spot a systemic email problem (a bad template, an expired sending domain) versus an isolated bounce.
- Cron jobs — scheduled job name, schedule, active state, last run and last status, covering the background ticks that roll up analytics, advance automations, dispatch scheduled campaigns and poll vendor status. If this tab is empty with an explanatory note, the underlying database RPC that exposes cron metadata isn't present on your instance yet; the cron tables themselves still exist and can be inspected directly.
- Audit log — actor, action, target and timestamp for administrative actions taken on the instance, useful for confirming who changed a setting before a symptom appeared.
A practical diagnostic order
- Run or check the messaging health card first — it isolates credentials, relay, send and inbound in one view.
- Check the Infobip and Cloudflare status cards to rule out a vendor incident.
- Check the metric tiles for a volume or failure spike in the last 24 hours.
- Open the relevant detail tab (webhooks, emails, cron, audit) to find the specific failing item and its error detail.
- If webhooks specifically are the problem, follow the dedicated diagnostic sequence in webhooks not arriving.
- If message delivery specifically is the problem, follow message not delivered, which covers consent, sender, template and window causes this page does not surface directly.
Because Platform → Health is admin-only, make sure at least one admin checks it routinely rather than waiting for a customer-reported symptom — the messaging health card in particular is designed to catch a broken send/receive path before it affects real conversations.
Frequently asked
Who can see the Platform health page?
Admin access is required. A non-privileged user opens the page and sees a plain notice that admin access is required, with no metrics shown — the health data is not exposed to ordinary agents.
What does the messaging health card actually test?
It runs a synthetic end-to-end check in four steps: Infobip credentials present, relay reachable, test send succeeds, and inbound message received. Each step shows pass, fail, warning or not-tested, so you can see exactly which stage of the send/receive path is broken rather than a single opaque status.
Does the messaging health test send to real customers?
No. It sends only to the designated test target you configure on the card (a specific WhatsApp or SMS number you control), never to real customer numbers, so you can run it as often as you like without any customer-facing side effect.
The Infobip or Cloudflare status card shows an outage — is that my instance or the vendor?
It is the vendor's own public status feed, polled on a schedule and shown for convenience so you don't have to leave the app to check. An outage shown there means the vendor has an incident, not necessarily that your instance is misconfigured — check your own messaging health card and webhook deliveries alongside it to confirm whether you're affected.
Why does the webhook deliveries tab show failures but Settings → Webhooks looks fine?
The Platform health page's webhook tab aggregates deliveries across every endpoint for the last 24 hours, while Settings → Webhooks lets you drill into one endpoint's own history and retry individual deliveries. A spike on one endpoint can be easy to miss in the per-endpoint view but obvious in the aggregate table — check both.
The cron jobs tab is empty — is that a problem?
Not necessarily. Cron metadata depends on database-level scheduling being exposed via an RPC helper; if that helper isn't present on your instance, the tab explains this and points at inspecting the underlying cron tables directly rather than showing a false 'no jobs' result.
Apply this to your own deployment
This guide describes decisions we make on live instances. Tell us your channels, systems and region and we will map it to an architecture outline, a provisioning plan and an indicative commercial model — usually within one business day.