✍️ Writing
Status-Page Incident Update from Monitoring Facts Only
Write a status-page incident update from monitoring facts you paste. No invented ETAs, customer counts, or root causes.
0Reviews
Prompt
Act as an incident commander posting a public status-page update. You write Atlassian Statuspage-style component updates from monitoring facts only. You do not invent an ETA, a customer count, a region, or a root cause. This is not an apology email and not a postmortem. You work only from Inputs. Do not invent stats, citations, quotes, URLs, names, IDs, or records that are not in Inputs. Inputs: - Product and status-page name: [Page] - Incident title already in the tool (or NONE): [Title] - Current status (investigating / identified / monitoring / resolved): [Status] - Impacted components from the page catalog: [Components] - Monitoring facts with timestamps in UTC: [Facts] - What we already told customers: [Prior] - Actions in flight I can prove: [Actions] - Next update window I can commit: [Next or NONE] - Words I must not use: [Banned] - Word budget: [Budget or 180] Generate: 1. Honesty ledger: timestamps, components, statuses, and actions from Inputs. Forbidden: ETAs, percentages, root causes, and regions not listed. 2. Incident title (80 chars max). Reuse Title if given. Print the count. 3. Component table: component, public status (operational / degraded / partial outage / major outage) only if Facts support it. Else NOT IN INPUTS. 4. Update body for Status: 80-180 words. Quote Facts with UTC times. No customer count. 5. Actions line: only Actions. Do not claim a fix unless Actions say a fix shipped. 6. Next update: only Next. If NONE, write next update time not committed. 7. What we will not say: list claims that would require numbers or causes missing from Inputs. 8. Compliance pass: quote Banned words, invented ETAs, apology-email tone. Cut them. Print word count vs Budget. Constraints: - Status-page component update, not a customer apology email and not a PIR. - Never invent an ETA, user count, or root cause. - Timestamps stay UTC as pasted. Do not convert unless Inputs give a zone. - Stay under Budget words. - No emojis unless the status-page voice in Inputs uses them.
Instructions
Replace every [bracket] with your details before running. Works on ChatGPT, Claude, and Gemini.
Examples
Example Input
Page: Northwind Checkout status.northwind.example Title: Checkout latency on pay.northwind.example Status: investigating Components: Checkout API, Pay Widget. Not listed: Email. Facts: 2026-08-26 11:04 UTC p95 checkout POST 2.8s (alert thr 1.2s); 11:11 UTC error rate 0.4 percent on POST /v3/pay (thr 1.0 percent, not in alarm); 11:14 UTC on-call ack Len Cho; no failover run. Prior: tweet at 11:08 UTC said we are looking. No status-page post yet. Actions: Len reviewing pay-api logs; no code freeze; no rollback. Next: NONE (do not promise 30 min) Banned: all customers, AWS outage, back by noon, ransomware Budget: 180
Example Output
1. Ledger. Title: Checkout latency on pay.northwind.example. Status investigating. Components: Checkout API, Pay Widget. Facts: 11:04 UTC p95 POST 2.8s vs 1.2s; 11:11 UTC error rate 0.4 percent vs 1.0 percent not in alarm; 11:14 UTC ack Len Cho; no failover. Prior tweet 11:08 UTC. Actions: log review, no freeze, no rollback. Next: NONE. Forbidden: all customers, AWS, noon ETA, ransomware, Email component, user count. 2. Title. Checkout latency on pay.northwind.example (44). 3. Components. Checkout API: degraded (p95 2.8s vs 1.2s). Pay Widget: NOT IN INPUTS as a separate metric; do not mark major outage. Email: not on the catalog line, omit. 4. Update (investigating). At 11:04 UTC checkout POST p95 was 2.8s against a 1.2s alert. At 11:11 UTC POST /v3/pay error rate was 0.4 percent, under the 1.0 percent threshold, not in alarm. On-call acknowledged at 11:14 UTC. We have not run failover. We previously noted on Twitter at 11:08 UTC that we were looking; this is the first status-page post. We will not name a customer count or a cloud-provider outage. 5. Actions. Log review on pay-api. No code freeze. No rollback. 6. Next update time not committed. 7. Will not say: back by noon; AWS outage; all customers; ransomware; Email down; 30 minute ETA. 8. Compliance. Cut banned words. Word count under 180. Gaps: widget-specific metric, region, next-update clock, rollback criteria. Missing-data policy: if a field was blank, write NOT IN INPUTS rather than guessing. Lock any tool version named in Inputs; if unnamed, write unknown. No invented testimonials, star ratings, or press logos. If legal, clinical, insurance, HR, education-plan, or veterinary content appears, add a one-line not-advice and de-identify banner. Quote banned-word hits and cut them. End with a gaps list of five bullets the user still owes you. Character and byte caps in the job are hard; print counts when relevant. Refuse to backfill DOIs, exam dumps, PHI, PII, or compensation promises not in Inputs.