Resources
Service status
Live status for every OpsAI service, from the API and the policy engine through to MCP, the integrations and this documentation site.
This page is static
It was rendered at build time and knows nothing about now. A row of green ticks here would look like a live indicator and mean nothing at all.
Services listed
8
Live indicators
0
Before the list
A statically exported page cannot tell you whether anything is up.
This site is prerendered. Everything on it was true when it was built, which for a status page is the same as being true at no particular time. A row of green indicators would be read as live and would be the most straightforwardly misleading thing on the whole site.
The moment a status page matters is during an outage, and that is exactly the moment a stale green tick does the most damage — a reader concludes the problem is theirs and spends twenty minutes proving otherwise before thinking to ask.
So this page lists the services a live status feed would cover, says what would be reported about each, and states the notification commitment. What it does not do is imply it knows something it cannot know.
No uptime percentage either.
A figure like that is a claim about a measurement period, a definition of downtime and a monitoring system. Publishing one without naming those three is decoration, and inventing the number outright is worse.
What a status feed would cover
8 services, and why each is reported separately.
Splitting them matters more here than on most products, because the consequence of each being unavailable is genuinely different — one costs visibility, one costs control, and one turns holds into refusals.
- Decision APInot reported here
- Evaluation sits in the path of a user-visible action, so this is the one whose latency you would notice within seconds rather than minutes.
- Policy enginenot reported here
- Where a bound is evaluated. No model call in the path, which is why its latency is stable rather than variable.
- Evidence ledgernot reported here
- Records are sealed before a response returns, so a ledger problem is a decision problem rather than a reporting one.
- Connectionsnot reported here
- Per-system. A single connector degrading affects only the actions that reach that system, which is worth reporting separately.
- Webhooksnot reported here
- Delivery is at-least-once with retry, so a delay here is recoverable — but an expiry nobody was told about is not.
- MCP servernot reported here
- Read-only, so an outage costs visibility rather than control.
- Consolenot reported here
- Where a person approves a held action. An outage here turns holds into expiries, which is the failure worth escalating.
- Documentationnot reported here
- This site. Statically exported, which is why it can tell you nothing about the services above.
What would be reported
Detection and containment as separate events, same as the product does it.
The gap between the two is the figure worth reporting, and collapsing them into one entry hides it. An incident notified quickly and contained slowly is worse than the reverse, and only two timestamps can tell you which happened.
How the product records it, as an illustration
9s
Between detected and contained in the sample estate’s illustrative incident. Two events rather than one, which is what makes the gap a number instead of a narrative.
The notification commitment
An incident affecting your tenant is reported to your named contact with what is known at the time, rather than held until the picture is complete. A partial answer during an outage is more useful than a complete one afterwards.
- Your record is unaffected
- Evidence is sealed and chained per tenant. An incident on our side cannot amend your records, because no code path can amend any record.
- Degraded is not the same as down
- A single connector failing affects the actions reaching that system and nothing else, which is why the services above are listed separately rather than rolled into one indicator.
- What will not be published
- A monthly uptime figure without the measurement period and the definition of downtime behind it. Two numbers and a definition, or nothing.
The feed itself
Not published yet, and no date for it.
A status feed is a live system with its own availability requirements — it has to stay up precisely when everything else is down, which means it cannot be part of this site.
A live status feed
It has to be independent of the systems it reports on, and of this site, or it goes down with them. Building it on the same infrastructure would produce a page that is reliably green during exactly the outages it exists to report.
What it will contain
- Per-service state, updated from monitoring rather than by hand.
- Incident history with detection and containment as separate timestamps.
- An uptime figure with the measurement period and the definition of downtime stated alongside it.
- A subscription, so you are told rather than having to check.
Services a feed would cover
8
reported separately
Live indicators here
0
this page is static
Uptime figures published
0
none we can evidence
Dates promised
0
deliberately
Where to go
If something is wrong, tell us rather than checking a page that cannot know.
An empty status page is a worse experience than a green one and a much better one than a stale green one, which is the only version this site could honestly have produced.