Every vendor is transparent until something breaks. When you have a bad incident, what do I actually see, and when?

The full executive answer

You see it where everyone sees it: the public status page, which covers seven subsystems — the web application, public API, AI generation, knowledge retrieval, webhooks, billing, and authentication — with the current state of each and the incident's update trail. Our incident model runs a disclosed lifecycle: open, investigating, contained, resolved, post-review, closed — and post-review is a formal stage, not an optional courtesy, so a resolved incident is not done until the review is.

Two design details show the intent. First, the status vocabulary is honest by construction — degraded, partial outage, major outage, maintenance — with roll-up logic that computes the overall banner from the worst component; there is no hand-set "all systems operational" override. Second, the incident model tracks jurisdiction notification deadlines with statuses like pending, imminent and overdue — so if an incident ever touches regulated notification duties, the countdown is machine-tracked rather than dependent on someone remembering.

What I will not claim: a track record. We have no public history of handling a major production incident with customers on the platform, because we are pre-launch — you are evaluating the machinery and the stated policy, not a portfolio of past incidents. The machinery is built and demonstrable; the reputation gets earned the only way it can be.