What it does
Writes what customers read during an outage, in the register that keeps trust rather than spending it. It drafts the status-page update and the matching reply for the tickets already piling up, keeps both saying the same thing, and refuses to invent the two details teams most often invent under pressure: a cause nobody has confirmed, and a time nobody can promise. Each update is written for the person refreshing the page, not for the engineers in the war room. What is broken, who it affects, what to do meanwhile, and when the next update comes — that last one being the only commitment worth making, because it is the only one you control. Nothing reaches a customer without a human approving it. Publishing to the status page and moving an incident to resolved are both gated, and the agent never marks anything resolved on its own: only a person who has confirmed recovery can say it is over. The support side matters as much as the page. Tickets arriving during an incident get an internal note linking the incident, so agents answer consistently instead of each inventing their own wording.
Example prompts
- Checkout is failing for about a third of users. Draft the first status-page update.
- We've been investigating for 40 minutes with no cause yet — write the next update.
- The fix is deployed and metrics look normal. Draft the monitoring update.
Before you connect
The credentials this agent will ask you for — the full setup is on the Setup tab.
Needs 2 credentials (1 required) to connect. See setup
