WhatsApp API status: how to read the Avox status page
A status page is only useful if it tells you who owns the problem. Here is what ours shows, how it decides, and the one case where it deliberately says nothing.
A customer writes to say your replies are arriving late. You check your phone, your Wi-Fi and the inbox. Everything looks fine from your side, and now you're guessing.
Is it your connection? Is it your WhatsApp tool? Is it WhatsApp itself? Each answer leads to a different next step, and the wrong guess costs you an hour. That's the whole case for a WhatsApp API status page: not to look reassuring, but to tell you whose problem it is.
We built a public one for Avox, and this post explains how to read it, how it decides what to show, and what it refuses to claim. Along the way we'll say why a status page matters for any WhatsApp tool, ours or someone else's.
What an honest status page has to do
Here are five rules we think any status page should follow, and that ours is built around.
- Be public, with no sign-in. If you need to log in to find out that logging in is broken, the page has failed.
- Separate who owns each part. Your messages pass through Avox and through WhatsApp's own systems, which Meta runs. A single green dot for both hides the thing you most need to know.
- Judge on evidence. A card shouldn't turn red because it was quiet at 3 a.m., or because one customer made a mistake.
- Say "no data" when there's no data. Grey is more honest than a made-up green.
- Show recent history. Resolved incidents stay on the page for 90 days, with how long each one lasted.
The Avox status page is at status.theavoxai.com. It needs no account and refreshes itself while it's open.
The page, top to bottom
At the top, a headline sums up the overall state in plain words: "Everything is running smoothly", "Some things need attention", or "We're working on a problem". Under it sits a button, Check everything again, which re-checks every service at once. Below that, a live heartbeat line, any ongoing incidents, then the service cards.
There are three groups of cards, 18 in all:
- Services (10): Core API, Database, Sign-in, WhatsApp webhooks, Avox API, Avox AI (Beta), Billing, Email delivery, Public APIs and Admin API.
- Tables, Flows and apps (4): Tables, Live Flows, Builder API and Connected apps. These are the things you build with.
- Meta / WhatsApp (4): WhatsApp Cloud API, Incoming messages, Message sending and Meta platform (reported by Meta).
Each card shows how quickly the service answered, when it was last checked, any open incident that names it, and 90 days of history as a row of daily bars. While the page is open, each service re-checks itself every 15 to 60 seconds, and the busiest paths are checked most often. In the background, every service is also checked about once a minute whether or not anyone is looking, and those records build the history.
The colours are plain: green is operational, amber is degraded (it works, but some requests may be slower or need a retry), red is an outage, and grey means no data.
WhatsApp API status: is it us, or is it WhatsApp?
This is the part we care about most. The Meta / WhatsApp group exists because Meta runs the platform underneath every WhatsApp message, and its slowdowns look, from your chair, exactly like ours.
When only the Meta side has trouble, the page says so directly. (We announced this split in a live status page, now with WhatsApp (Meta) on its own.) The headline reads "WhatsApp (Meta) is having issues", and the mascot at the top says "Avox is up, WhatsApp (Meta) is having issues". You can stop restarting things and wait, or tell your own customers, knowing the fault isn't in your setup.
For the last card in that group, Meta platform (reported by Meta), we pass along what Meta's own status page says about the parts of its platform Avox uses. The card links to it, and you can also open Meta's status page for business products yourself.
How the Meta cards decide
We don't turn a Meta card amber or red because we feel nervous. These cards change only on clear signs of trouble: Meta not answering, most recent messages arriving late, or many sends failing on Meta's side. Quiet hours with little traffic leave a card green.
And one account's trouble never moves the public page. Sending problems count only when they show up across more than one Switchboard, so a business with a broken number can't make the status page claim an outage for everyone.
What it won't claim
Two rules here take a bit of restraint.
Only Avox's own problems count. For Tables, Live Flows, the Builder API and Connected apps, the cards are judged on recent requests and background work. A mistake in a request, a refused key, a full table or one app being down never turns a card amber. Connected apps goes amber only when calls to two or more different apps fail at once, which is the sign that Avox's own way out is struggling.
Grey stays grey. Until a feature is switched on, its card shows "No data". That isn't written into the history as a good day, it doesn't count against the overall status, and it isn't counted in "Services up". We'd rather leave a gap than draw a bar we can't stand behind.
Even the uptime percentage on each card is rounded down, never up, so a figure like 99.996 can't be dressed up as a clean 100. We don't quote percentages in this post, because the page changes by the minute and the live card is the only place a number is true.
History and monitoring
Incidents, written down
Problems appear two ways. The Avox team can post one, with a title, an impact (Notice, Minor, Major or Critical), the services it affects, and a status that moves through Investigating, Identified, Monitoring and Resolved, with a timestamped update at each step. Or the checks can find one themselves: a run of failed checks is recorded as an incident on its own, marked "Found automatically". If both describe the same event on the same service, you only see the one the team wrote.
Resolved incidents stay under Past incidents for 90 days with how long each lasted.
Watching it from your own tools
If you run your own monitoring, the same data is available as plain JSON. A request to https://status.theavoxai.com/api/health returns the overall state, split into an Avox group and a Meta group, plus every service. The HTTP status follows the core service: 200 while it's up, 503 when it isn't. To watch one service, add ?service= with its key, for example ?service=messaging for the Avox API. Checking once a minute is plenty, and going faster returns a 429 with a Retry-After header.
Questions people ask
Is WhatsApp down right now?
Open the status page and look at the Meta / WhatsApp group. If those cards are green but a card in the Avox groups is amber or red, the trouble is on our side. If the headline says "WhatsApp (Meta) is having issues", the fault is upstream. Meta's own page is linked from the page too, and Meta's current statements are the authority on its platform.
The status page is all green, but something is wrong for me. Why?
A public page can only see what every customer sees. Your number has its own quality rating and limits, which live on the Health page in your dashboard. If both look fine, open a ticket from Support and include the time it happened.
Will I be told about planned maintenance?
Notices such as planned maintenance appear in the dashboard's notification bell and can also be emailed. The status page itself is for live health and incidents.
One thing to do today
Bookmark the status page on the device your team uses, and open the Meta / WhatsApp group once while everything is green, so you know what normal looks like. Then, if you want an alert, point your own uptime monitor at the health address above. The full guide is on the status page docs.
Thanks for reading
How did this land?
Was this helpful?
Try it yourself
Is WhatsApp down, or is it us? Reading WhatsApp API status on the Avox status page: our health versus Meta's, what each colour means, and how to check it.
Follow Avox on Google
Pick Avox as a preferred source and Google shows our stories more often in Top Stories and its search results.