openstatushq Status Report
Write periodic status reports that give stakeholders a clear picture of system health, reliability trends, and what's being done to improve.
When to Use
- "write a weekly status report"
- "draft our monthly uptime report"
- "summarize system health for this quarter"
- "write a reliability report for stakeholders"
Workflow
1. Check for Context
Read .agents/status-page-context.md if it exists. Use it for:
- Component names — report on the right services
- SLA targets — compare actual uptime against commitments
- Severity levels — classify incidents consistently
- Tone — match the team's communication style
If the file doesn't exist, suggest running the status-page-context skill first. Proceed without it if the user wants to skip.
2. Determine Report Type
Ask the user if not obvious:
| Type | Cadence | Audience | Focus |
|---|---|---|---|
| Weekly | Every week | Internal team, stakeholders | Recent incidents, upcoming maintenance, quick health snapshot |
| Monthly | Every month | Customers, leadership | Uptime metrics, incident summary, trends, improvements |
| Quarterly | Every quarter | Leadership, board, customers | Reliability trends, SLA performance, strategic improvements |
| Ad-hoc | As needed | Varies | Specific topic (e.g., post-migration health, new region launch) |
3. Gather Data
Ask the user for or help them collect:
Required:
- Reporting period (exact date range)
- Uptime numbers per component (or overall)
- Number and severity of incidents during the period
- Any scheduled maintenance that occurred
Important (include if available):
- SLA target vs actual comparison
- Error budget status (consumed/remaining)
- Mean time to detect (MTTD), mean time to resolve (MTTR)
- Incident trends (improving, stable, worsening)
- Notable incidents with brief descriptions
Optional:
- Performance metrics (latency, throughput)
- Upcoming planned maintenance
- Reliability improvements shipped
- Customer-reported issues
4. Write the Report
Follow these principles:
Principle 1: Lead with the headline number
The first thing readers want to know: how did we do?
Do: "Overall uptime for March 2026: 99.97% (target: 99.9%). Zero critical incidents." Don't: Start with a paragraph about the team's efforts.
Principle 2: Compare against targets
Raw numbers without context are meaningless. Always compare to SLA targets or previous periods.
Do: "API uptime: 99.95% (target: 99.9%) — 0.05% above target. Error budget: 62% remaining." Don't: "API uptime: 99.95%." (Is that good? Bad? On track?)
Principle 3: Be honest about bad periods
A status report that only highlights good metrics loses credibility. Address misses directly.
Do: "Webhook delivery uptime dropped to 99.2% this month, below our 99.5% target. This was driven by the March 14 incident (see below). We've shipped [fix] to prevent recurrence." Don't: Omit components that missed their targets.
Principle 4: Show trends, not just snapshots
One month's number doesn't tell a story. Compare to previous periods.
Do: "MTTR improved from 45 min (Feb) to 28 min (Mar), driven by the new automated rollback system." Don't: "MTTR: 28 minutes." (Better or worse than before?)
Principle 5: Connect incidents to improvements
Every incident mentioned should link to what was done about it. This builds trust.
Do: "March 14 — Webhook delivery failure (47 min). Root cause: connection pool exhaustion. Fix shipped: automated pool scaling + alert at 80% capacity." Don't: "March 14 — Webhook delivery failure (47 min)." (And then?)
Principle 6: End with what's next
Forward-looking items show the team is proactive, not just reactive.
Do: "Upcoming: Database migration (April 3, 02:00-04:00 UTC), new monitoring for edge regions, SLA review for Q2." Don't: End abruptly after the metrics.
Report Templates
Weekly Status Report
# Weekly Status Report: [Date Range]
## Summary
[1-2 sentences: overall health this week. Lead with the headline.]
## Uptime
| Component | Uptime | Target | Status |
|-----------|--------|--------|--------|
| [Component] | [%] | [%] | [On target / Below target] |
## Incidents This Week
| Date | Severity | Component | Duration | Summary |
|------|----------|-----------|----------|---------|
| [Date] | [Sev] | [Component] | [Duration] | [One-line summary + fix status] |
[If no incidents: "No incidents this week."]
## Maintenance
| Date | Component | Duration | Status |
|------|-----------|----------|--------|
| [Date] | [Component] | [Duration] | [Completed / Scheduled] |
## Looking Ahead
- [Upcoming maintenance]
- [Reliability improvements in progress]
- [Anything the team should be aware of]
Monthly Status Report
# Monthly Status Report: [Month Year]
## Executive Summary
[2-3 sentences: how the month went, headline metrics, key events.]
## Uptime & SLA Performance
| Component | Uptime | SLA Target | vs Target | vs Last Month |
|-----------|--------|------------|-----------|---------------|
| [Component] | [%] | [%] | [+/- %] | [+/- %] |
**Overall uptime:** [%]
**Error budget consumed:** [%] ([remaining]% remaining for [period])
## Reliability Metrics
| Metric | This Month | Last Month | Trend |
|--------|-----------|------------|-------|
| Incidents (total) | [N] | [N] | [direction] |
| Critical incidents | [N] | [N] | [direction] |
| MTTD (mean time to detect) | [min] | [min] | [direction] |
| MTTR (mean time to resolve) | [min] | [min] | [direction] |
## Incident Summary
### [Incident title] — [Date]
- **Severity:** [Level]
- **Duration:** [X min/hours]
- **Impact:** [What users experienced]
- **Root cause:** [1 sentence]
- **Fix:** [What was done]
- **Postmortem:** [Link or "published" or "in progress"]
[Repeat for each notable incident. Minor incidents can be summarized in a table.]
## Maintenance Summary
[Table of maintenance windows with component, date, duration, outcome.]
## Improvements Shipped
- [Reliability improvement with brief description of what it prevents]
- [Monitoring improvement]
- [Process improvement]
## Looking Ahead
- **Upcoming maintenance:** [Dates and components]
- **In progress:** [Reliability work underway]
- **SLA review:** [Any target changes under consideration]
---
*Next report: [Date]*
Quarterly Status Report
# Quarterly Reliability Report: [Q# Year]
## Executive Summary
[3-5 sentences: quarter performance, key wins, key challenges, strategic outlook.]
## Quarterly Metrics
| Metric | Q[N] | Q[N-1] | Q[N-2] | Trend |
|--------|------|--------|--------|-------|
| Overall uptime | [%] | [%] | [%] | [direction] |
| Critical incidents | [N] | [N] | [N] | [direction] |
| Total incident minutes | [N] | [N] | [N] | [direction] |
| MTTD | [min] | [min] | [min] | [direction] |
| MTTR | [min] | [min] | [min] | [direction] |
| Error budget remaining | [%] | [%] | [%] | [direction] |
## SLA Performance by Component
| Component | Q[N] Uptime | SLA Target | Met? |
|-----------|-------------|------------|------|
| [Component] | [%] | [%] | [Yes/No] |
## Notable Incidents
[Top 3-5 incidents by severity/impact with brief summaries and links to postmortems.]
## Reliability Investments
### Shipped This Quarter
- [Initiative]: [Impact/result]
### In Progress
- [Initiative]: [Expected completion, expected impact]
### Planned for Next Quarter
- [Initiative]: [Why, expected impact]
## Lessons Learned
- [Key takeaway from the quarter's incidents]
- [Pattern or trend identified]
- [Process or cultural insight]
## Outlook
[2-3 sentences on focus areas for next quarter.]
---
*Next quarterly report: [Date]*
Anti-patterns to Avoid
| Anti-pattern | Why it's bad | Instead |
|---|---|---|
| "All systems operational" with no data | Provides no transparency or accountability | Show uptime numbers against targets |
| Only reporting good metrics | Erodes trust when stakeholders discover omissions | Address misses directly with root cause and fix |
| Raw numbers without context | "99.95%" means nothing without the target | Always compare: vs target, vs last period |
| Listing incidents without fixes | Feels like a problem list, not a report | Connect every incident to what was done about it |
| Skipping months with no incidents | Inconsistency in reporting cadence | Still publish — "No incidents this month" is a positive signal |
| Overly long reports | Nobody reads them | Keep weekly to 1 page, monthly to 2 pages, quarterly to 3-4 pages |
Related Skills
status-page-context— Set up the context document this skill reads (components, SLA targets, tone)incident-communication— Write updates during active incidents (referenced in incident summaries)postmortem— Write detailed postmortems (linked from incident summaries)maintenance— Write maintenance announcements (referenced in maintenance summaries)