1. Agents pause
Automated processing stops first. Losing a day of coding suggestions is an inconvenience; a half-posted close is an incident. This ordering is deliberate.
Status
Current status, twelve months of availability including the three months we missed target, and every customer-affecting incident with its cause and its fix. A reliability figure you cannot check is marketing.
Customers are notified directly. Anyone else can ask to be added to incident and maintenance notices.
2 of 12 months fell below the 99.9% target (Dec 25, Mar 26). Worst month: 99.72%. We publish these because a reliability figure you cannot check is marketing.
A read-model rebuild consumed more database connections than provisioned, slowing queries and reports. Ledger posting was unaffected throughout. Fixed by isolating rebuild capacity and adding a connection ceiling.
A connector deploy dropped webhook deliveries from two payment providers. No data was lost — the replay window recovered every missed event once the endpoint recovered. Fixed by gating deploys behind delivery-queue drain.
Agents paused automatically under elevated model-provider latency, as designed. User actions and posting continued normally. No customer action was required.
Under failure
Everything fails eventually. The design question is what fails first and what that costs you, and most vendors avoid answering it because answering requires admitting a failure model exists.
Automated processing stops first. Losing a day of coding suggestions is an inconvenience; a half-posted close is an incident. This ordering is deliberate.
Scheduled reports, exports, and non-urgent syncs queue rather than fail. They resume in order once capacity returns.
New transactions are refused rather than partially accepted. Nothing posts halfway — every ledger write is atomic and idempotent.
Reading your data survives longest. Ledger posting is the last capability to go and the first restored.
Availability is measured against successful request handling, not against whether a server responds to a ping. A system that returns errors quickly is unavailable, and measuring it any other way produces a number that flatters the vendor and misleads the customer.
A month is measured from the first to the last day, and a partial outage counts proportionally: if 30% of requests failed for an hour, that is eighteen minutes of downtime rather than none.
Anything customer-affecting, including partial degradation. The March 2026 entry was a slow-query incident where posting worked normally throughout — we still logged it, published it, and wrote it up, because a customer whose reports were slow experienced an incident regardless of what our infrastructure dashboard said.
Agent pauses under provider latency are recorded as partial incidents even though they are the system behaving as designed. If automation you were relying on stopped, you should be able to see that it stopped and why.
Customers are notified directly for any incident affecting their tenant, not left to discover it on this page. For anything customer-affecting we publish a post-mortem with the cause and the fix rather than a note about elevated error rates.
Scheduled maintenance is announced in advance and performed outside United States business hours where practicable. Emergency maintenance may happen without notice where security or data integrity requires it, and is written up afterwards.
Three of the last twelve months fell below target, and the worst was 99.72%. Showing that costs us in evaluations against vendors who publish a single flattering figure with no method behind it. It also means that when we say a month was clean, it is checkable — which is the only thing that makes the good months worth anything.
Questions
Recovery objectives, degradation behaviour, exit path. We would rather answer them now than during an incident.