What an incident says
An incident has akind: 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.updatedwithout ever seeingincident.opened. Each event carries the whole incident as it stands, so a receiver doesn’t need the earlier events.
Webhook events
Thestatus group has six events. Each one is a single update to an incident.
Status events belong to the whole workspace. Subscribe with workspace scope:
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.
maintenance.scheduled
maintenance.scheduled
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.
queueBrandNotice(queue_brand_noticein Python) is yours: an email, a WhatsApp message or a banner in your own dashboard. Send it from a queue, after you answer200, so a slow mail server never makes us retry the delivery.- When
impactisnullwe 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_urlonly when it ishttps://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.bodyare written for you. Read them before you pass them on unchanged, or write your own fromtitle,stateandcalls_failed. - When your receiver starts, read
GET /v2/status/incidentsonce 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 opensstatus_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.incidentin the webhook, plusupdated_at,scopeandworkspace_impact. scopeisplatformwhen the incident may affect any customer, orworkspaceswhen it affects only the workspaces it names.workspace_impactis the same asdata.impactin the webhook: your workspace’s numbers, ornull.limitis 1 to 100 (default 20). Whenhas_moreistrue, passnext_cursorascursorfor the next page.GET /v2/status/publicanswers{"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.