Skip to main content
When part of the platform is down, slow, or due for planned maintenance, we write it up as an incident. The emails, webhook events and status API below all read that one record, so they never disagree. The status page runs its own checks of each part, around the clock.

What an incident says

An incident has a kind: incident for something that went wrong, or maintenance for work we planned. Maintenance only moves forward, and its window is at most 7 days long. impact is how bad it is: degraded (slower or less reliable than usual), partial_outage (partly down) or major_outage (down). components names the parts it touches, from this fixed list:

Who is told

  • An incident on the public status page goes to every workspace that subscribes to its event. Its emails go to the owners of every live account.
  • Any other incident goes only to the workspaces it names: the ones we know it touched. Nobody else can read it.
  • If we name your workspace after an incident has started, you get its latest update straight away. So you can receive incident.updated without ever seeing incident.opened. Each event carries the whole incident as it stands, so a receiver doesn’t need the earlier events.
Each workspace sees only its own numbers: its agents, its failed calls, and whether those calls were charged.

Webhook events

The status group has six events. Each one is a single update to an incident. Status events belong to the whole workspace. Subscribe with workspace scope:
An agent subscription that lists a status event is refused with 400. To test your receiver, send {"if_revision": 1, "event_type": "incident.opened"} to POST /v2/webhooks/endpoints/{id}/test. The test carries made-up data and "test": true.

Payload

Status events use the same envelope, signature and retries as every other subscription event.
Events can arrive out of order. Keep the highest latest_update.seq you have handled for each incident and ignore any update with a lower one.

Forward notices to your own customers

If you run voice agents for other brands, your brands should hear about a problem from you, before they notice it themselves. impact.agents tells you which of your agents an incident touched, so you can tell only the brands it affected. The receiver below keeps a map from agent id to brand. It checks the signature, drops repeats, test events and stale updates, then adds up failed calls per brand and queues one notice for each.
A few things to decide on your side:
  • queueBrandNotice (queue_brand_notice in Python) is yours: an email, a WhatsApp message or a banner in your own dashboard. Send it from a queue, after you answer 200, so a slow mail server never makes us retry the delivery.
  • When impact is null we have no numbers for your workspace. The example then tells every brand, which suits maintenance and platform-wide incidents. Change that if you would rather wait for numbers.
  • Link brands to status_url only when it is https://status.miraiminds.co. For any other incident it opens the Status page in your console, which your brands can’t sign in to.
  • Our words in latest_update.body are written for you. Read them before you pass them on unchanged, or write your own from title, state and calls_failed.
  • When your receiver starts, read GET /v2/status/incidents once to catch anything it missed while it was down.

Status emails to owners

Your account’s owners get an email for every incident and maintenance update that concerns you. You don’t need to set anything up. Other people on your team don’t get them. An update concerns you when the incident names one of your workspaces, or when it is on the public status page and your account is live. You get one email per update. It shows the state, the impact, the parts affected and when it started, or the maintenance window in IST. If calls failed, it lists your agents that had failures (up to 8, then “and N more”), your total failed calls, and whether they were charged. If you run brands as sub-workspaces and more than one is affected, each agent is listed with its brand. The See status button opens status_url. Emails go out after the webhook events, usually within about 15 seconds. To leave a workspace out, turn status_email off:
Response
GET /v2/webhooks/settings shows the current value. It is true until you change it. The setting covers one workspace. When every workspace an update concerns has it off, no email goes out. It does not change webhook events or email endpoints. An owner who already gets the same update through one of your email endpoints, for every workspace the email would cover, is not sent a second copy.

Read incidents with the API

Response
  • An incident has the same fields as data.incident in the webhook, plus updated_at, scope and workspace_impact.
  • scope is platform when the incident may affect any customer, or workspaces when it affects only the workspaces it names.
  • workspace_impact is the same as data.impact in the webhook: your workspace’s numbers, or null.
  • limit is 1 to 100 (default 20). When has_more is true, pass next_cursor as cursor for the next page.
  • GET /v2/status/public answers {"object": "status_feed", "incidents": [...]} with up to 50 incidents and 50 updates each. It may be cached for 30 seconds.
  • If incident records are briefly unavailable, these routes answer 503 status_unavailable. Retry after a short wait.

The status page

status.miraiminds.co shows whether each part works right now, and its uptime for the last 90 days. A server in Germany, apart from the servers that run your calls, does the checking and serves the page, so the page stays up when the platform is down.

What it checks

A call fails on our side when it ends for a technical reason, or times out before any audio. A caller who doesn’t answer, is busy or hangs up is not a failure, and neither is a call stopped for low balance. The page also shows the reply time on real calls over the last hour and the last 24 hours: a typical turn, and the slowest 1 in 20. Reply time runs from when the caller stops talking to the agent’s first sound.

How outages are counted

  • One failed check is noise. Two failed checks in a row start an outage. It runs from the first failed check until the next check that passes.
  • A part is down while any of its checks is in an outage.
  • A campaign-calls check fails when a quarter or more of those calls failed on our side. With fewer than 10 calls in the last hour, the page shows Quiet instead of counting the part as up.
  • A day’s uptime is the share of the time we were measuring that day (IST) that was not inside an outage. A day we did not measure shows as not measured, never as 100%.
  • Outages of 2 minutes or more are listed one by one. Shorter drops are counted, not listed.
  • If the page’s numbers are more than 5 minutes old, it says so. The checker may be down while the products are fine.