Avox Status Page and Health Checks

What each service on the Avox status page means, how often it's checked, how incidents are posted, and how to monitor Avox from your own tools.

The Avox status page at api.avox.com/status shows the live health of every part of Avox - the dashboard, your WhatsApp messages, the Avox API and Avox AI - and of the WhatsApp services Meta runs underneath them. It's public, needs no sign-in, and refreshes itself while it's open. The Status link at the bottom of this site's sidebar opens it.

What's on the page#

From top to bottom:

• The mascot and headline - the Avox mascot sums up the overall status in its thought bubble, with a headline under it: "Everything is running smoothly", "Some things need attention" or "We're working on a problem". Under it, Check everything again re-checks every service.
• Live heartbeat - a pulse line in the colour of the current status, the database response time in milliseconds, how many services are up, and when the newest check came in.
• Ongoing incidents - right under the heartbeat, every incident the Avox team is working on, with all its updates. When there are none, a single line says "No ongoing incidents - everything is running normally."
• Services - one card per service (see below), then the Meta / WhatsApp group (see Meta / WhatsApp).
• Past incidents - the last 90 days of incidents in one timeline (the 20 most recent), or "No incidents in the last 90 days."
• Links - API documentation, Open the dashboard, avox.com and Status as JSON.
• Helpful docs and Questions - guides for the things the page watches and a short FAQ.
• Footer - links to avox.com, the docs, contact, email preferences, the legal pages, Cookie settings, and the support address.

The services#

Each card shows the service's name, what it covers, its live state, how quickly it answered (in milliseconds), how often it's re-checked, when it was last checked, any open incident that names it, and 90 days of history.

The Key is the name to use with the health endpoint (see Monitoring Avox from your own tools).

Meta / WhatsApp#

Under the Avox services, a second group, Meta / WhatsApp, shows the side of WhatsApp that Meta runs: "Run by Meta. Every WhatsApp message goes through these, so when they struggle messages can be slow even though Avox itself is fine."

How these are judged:

• Only on evidence. A Meta service turns amber or red only when there's a clear sign of trouble - for example Meta not answering, most recent messages arriving late, or many sends failing on Meta's side. Quiet hours with little traffic leave it green.
• Never one account. Sending problems count only when they show up across several Switchboards, so a problem with one business's own number never changes the public status.
• Meta's own report reflects the parts of Meta's platform that Avox uses, such as the Cloud API, Coexistence, Calling, Embedded Signup and Flows.

When only the Meta side has trouble, the page says so plainly: the headline reads WhatsApp (Meta) is having issues and the mascot says "Avox is up, WhatsApp (Meta) is having issues", so you can tell a WhatsApp slowdown apart from a problem with Avox. For your own number, Meta's quality and limits are on Health.

How often each service is checked#

There are two kinds of checks:

• While the page is open, each service is re-checked on its own schedule - every 15 to 60 seconds, as listed above and printed on each card ("Refreshes every 15s"). The busiest paths are checked most often. A card says "checking now" while its check runs, and "couldn't refresh" if a check didn't get through - the last answer stays on screen until the next one arrives.
• In the background, every service is also checked about once a minute, all day, whether anyone has the page open or not. Those recordings build the 90-day history bars and the uptime percentages.

To re-check everything at once, select Check everything again under the headline, or press and hold the mascot. While another browser tab is in front, the page pauses its checks; it checks again as soon as you come back.

Colours#

In the 90-day bars, a day turns red after a few minutes of outage and amber for any trouble at all that day. Hover or tap a bar for that day's details. Each card's uptime percentage is the share of that service's checks over the period that weren't an outage; it's never rounded up to a misleading 100%. On a phone, the bars show the last 30 days.

The overall status is the worst of all the services. An open incident the team has posted counts too, even while the automatic checks look fine: a Minor or Major incident makes the page amber and a Critical one makes it red.

The mascot#

The mascot at the top is the same Avox Avatar you see across the dashboard, here wearing the page's status colour. Its face follows the overall status:

Its thought bubble states the overall status in plain words, then rotates through a few friendlier ways of saying the same thing (screen readers only hear the plain status, and only when it changes). Tap the mascot for a little reaction; press and hold it to re-check every service.

Incidents#

Incidents appear in two ways:

• Posted by the Avox team. When the team is working on a problem it appears under the Live heartbeat and on the card of every service it affects. Each incident has a title, an impact - Notice, Minor, Major or Critical - the services it affects, when it started, and a status that moves through Investigating, Identified, Monitoring and Resolved, with a timestamped update at each step (newest first). Times are shown in UTC.
• Found automatically. A run of failed background checks is recorded as an incident on its own - for example "Database degraded" - with how long it lasted and the note "found by our automatic checks".

Once resolved, both kinds stay in Past incidents for 90 days, with how long each one lasted. A resolved posted incident keeps its updates behind Show the update (or Show 3 updates, and so on). When a posted incident and an automatic one describe the same event on the same service, only the posted one is shown.

News, maintenance and changes#

The status page is for live health and incidents. For everything else:

• Announcements on avox.com/announcements - product news from the Avox team, with an RSS feed and an optional email.
• Dashboard notifications - notices such as planned maintenance appear in the dashboard's notification bell, and can also be emailed. See Emails.
• The docs Changelog - every new feature, improvement and fix, with its own RSS feed.

Monitoring Avox from your own tools#

The status page reads a public, read-only health endpoint that you can point your own uptime monitor at. It needs no key, is never cached, and every answer includes the time of the check.

Everything at once#

curl -i https://api.avox.com/api/health

{
  "ok": true,
  "status": "operational",
  "overall": "operational",
  "groups": { "avox": "operational", "meta": "operational" },
  "checkedAt": "2026-10-10T09:30:00.000Z",
  "checks": {
    "api": { "ok": true, "ms": 4 },
    "database": { "ok": true, "ms": 38 }
  },
  "components": [
    { "id": "api", "name": "Core API", "status": "operational", "ms": 4, "checkedAt": "2026-10-10T09:30:00.000Z" },
    { "id": "database", "name": "Database", "status": "operational", "ms": 38, "checkedAt": "2026-10-10T09:30:00.000Z" }
  ],
  "services": ["... the same list as components ..."]
}

• The HTTP status follows the core service (the API and the database): 200 while it's up, 503 when it isn't. That makes it a drop-in check for any monitor that only looks at the status code.
• ok and status describe the core service too (status is operational or degraded).
• overall is the worst state across every service: operational, degraded or down.
• groups splits that by who runs the service: groups.avox for Avox's own services and groups.meta for the Meta / WhatsApp ones.
• components lists every service with its id (the key from the table above), name, status, response time ms (or null) and checkedAt. services is the same list under the name the status page uses. (The example above is shortened to two services.)

One service#

Add ?service=<key> to watch a single service - for example, only the Avox API if that's all your integration uses:

curl https://api.avox.com/api/health?service=messaging

{
  "ok": true,
  "service": {
    "id": "messaging",
    "name": "Avox API",
    "status": "operational",
    "ms": 12,
    "checkedAt": "2026-10-10T09:30:00.000Z"
  }
}

• The answer is always 200 for a known key. ok is false only when that service is down; read service.status to also catch degraded.
• An unknown key returns 400 with { "error": "unknown_service" }.
• Checking too often returns 429 with { "error": "rate_limited" } and a Retry-After header (in seconds). Once a minute per service is plenty.

// Alert when the Avox API is degraded or down. Run it once a minute.
const res = await fetch("https://api.avox.com/api/health?service=messaging");

if (res.status === 429) {
  const wait = Number(res.headers.get("Retry-After") ?? 60);
  console.log(`Checked too often - try again in ${wait}s`);
} else {
  const { service } = await res.json();
  if (service.status !== "operational") {
    console.warn(`${service.name} is ${service.status} (checked ${service.checkedAt})`);
  }
}

# Alert when the Avox API is degraded or down. Run it once a minute.
import requests

res = requests.get("https://api.avox.com/api/health", params={"service": "messaging"}, timeout=10)

if res.status_code == 429:
    print(f"Checked too often - try again in {res.headers.get('Retry-After', '60')}s")
else:
    service = res.json()["service"]
    if service["status"] != "operational":
        print(f"{service['name']} is {service['status']} (checked {service['checkedAt']})")

Last updated 12 October 2026