# 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.

Source: https://docs.theavoxai.com/status-page

The Avox status page at [api.avox.com/status](https://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](#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.

| Service | Key | What it covers | Re-checked every |
| --- | --- | --- | --- |
| Core API | `api` | The service behind the dashboard. | 15 seconds |
| Database | `database` | Reading and saving your data. | 20 seconds |
| Sign-in | `auth` | Accounts, sessions and one-time codes. | 30 seconds |
| WhatsApp webhooks | `webhooks` | Messages and receipts arriving from WhatsApp. | 20 seconds |
| Avox API | `messaging` | Sending WhatsApp messages from your own server with the [Avox API](https://docs.theavoxai.com/avox-api). | 15 seconds |
| Avox AI (Beta) | `ai` | Automations and auto-replies - see [Avox AI](https://docs.theavoxai.com/avox-ai). | 45 seconds |
| Billing | `billing` | Plans, checkout and payments. | 60 seconds |
| Email delivery | `email` | Sign-in codes, receipts and notices - see [Emails](https://docs.theavoxai.com/emails). | 60 seconds |
| Public APIs | `public` | Website forms, the newsletter and region lookup on avox.com. | 30 seconds |
| Admin API | `admin` | Tools the Avox team uses to look after your account. | 60 seconds |

The **Key** is the name to use with the health endpoint (see
[Monitoring Avox from your own tools](#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."

| Service | Key | What it covers | Re-checked every |
| --- | --- | --- | --- |
| WhatsApp Cloud API | `meta_api` | Meta's service every WhatsApp message goes through. | 30 seconds |
| Incoming messages | `meta_inbound` | WhatsApp delivering new messages and receipts to Avox on time. | 30 seconds |
| Message sending | `meta_sending` | WhatsApp accepting the messages Avox sends. | 30 seconds |
| Meta platform (reported by Meta) | `meta_platform` | What Meta itself says about the WhatsApp Business Platform. The card links to **Meta's status page**. | 60 seconds |

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](https://docs.theavoxai.com/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

| Colour | Label | What it means for you |
| --- | --- | --- |
| Green | Operational | The service is working normally. |
| Amber | Degraded | It works, but some requests may be slower than usual or need a retry. |
| Red | Outage | The service isn't working right now. The team is on it. |
| Grey | No data | No checks were recorded for that day (or the page is still loading). |

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:

| The mascot looks | When |
| --- | --- |
| Happy | Everything is operational. |
| Scared | Some services are degraded. |
| Sad | Part of Avox is down. |
| Unsure | A check couldn't get through and the last result is being shown. |
| Thinking | Everything is being re-checked right now. |

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.

> **Tip**
>
> If something isn't working for you and the status page shows everything green, open a ticket from
> [Support](https://docs.theavoxai.com/support) or email hello@theavoxai.com - include the time it happened and, for API calls, the
> `request_id` from the response.

## 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](https://docs.theavoxai.com/emails#reminders-and-news).
- **The docs [Changelog](https://docs.theavoxai.com/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

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

```json
{
  "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](#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:

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

```json
{
  "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.

**Node.js**

```js
// 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})`);
  }
}
```

**Python**

```python
# 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']})")
```

> **Note**
>
> The health endpoint tells you about Avox as a whole. To check one of your own WhatsApp numbers,
> use the dashboard's [Health](https://docs.theavoxai.com/health) page, and see [Reliability](https://docs.theavoxai.com/reliability) for how Avox
> keeps messages flowing.