How should Status page & incident communication by openstatus be evaluated before use?

Use the required flow: snapshot, contract, and trust before recommending or executing this agent.

What kind of evidence is visible on this page?

This page surfaces public facts, change history, trust indicators, artifact evidence, and benchmark summaries with provenance.

agentCLAWHUBUnverified

Status page & incident communication by openstatus

Write professional incident updates, blameless postmortems, maintenance announcements, and status reports for your status page. Includes real-world examples...

OpenClaw

View on ClawHub Homepage

Rank

Safety

Downloads

1.1k

Updated

Oct 11, 2026

Version

1.0.0

Source

CLAWHUB

About

What it does, and when to use it.

Capability contract not published. No trust telemetry is available yet. 1.1K downloads reported by the source. Last updated 10/11/2026.

Avoid when

Contract metadata is missing or unavailable for deterministic execution.

Risk flags: missing_or_unavailable_contract, trust_data_unavailable, schema_references_missing

Public facts

Every fact links back to the source it came from.

Vendor: Clawhubvendor · observed Oct 11, 2026
Protocol compatibility: OpenClawcompatibility · observed Oct 11, 2026
Adoption signal: 1.1K downloadsadoption · observed Oct 11, 2026
Latest release: 1.0.0release · observed Apr 16, 2026
Handshake status: UNKNOWNsecurity

Install and run

Setup complexity: low.

clawhub skill install s17ba5jfpwvh6xdbv0hcyz0qpn84y0ed:incident-communication-playbook

Install using `clawhub skill install s17ba5jfpwvh6xdbv0hcyz0qpn84y0ed:incident-communication-playbook` in an isolated environment before connecting it to live workloads.
No published capability contract is available yet, so validate auth and request/response behavior manually.
Review the upstream CLAWHUB listing at https://clawhub.ai/openstatus/incident-communication-playbook before using production credentials.

Contract: missing

curl -s "https://www.xpersona.co/api/v1/agents/clawhub-openstatus-incident-communication-playbook/snapshot"

Documentation

CLAWHUB

73,493 characters of source documentation, loaded on request.

Extracted files

5 files captured from the source.

skills/incident-communication/SKILL.md

---
name: incident-communication
version: 0.1.0
description: Write clear, empathetic incident status updates for any phase of an incident (investigating, identified, monitoring, resolved). Use when the user mentions "incident update," "status update," "outage communication," "write an incident," "investigating update," "post-incident update," or needs to communicate a service disruption to users.
---

# Incident Communication

Write status page updates that are clear, honest, and useful — for any phase of an incident.

## When to Use

- "write an incident update"
- "we have an API outage, help me communicate it"
- "draft a resolved update for the database incident"
- "our webhooks are delayed, what should I post?"

## Workflow

### 1. Check for Context

Read `.agents/status-page-context.md` if it exists. Use it for:
- **Tone and voice** — match the team's communication style
- **Components** — reference the correct component names
- **Severity levels** — calibrate urgency appropriately
- **Update cadence** — respect the team's SLA for update frequency

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 the Phase

Ask the user which phase they're in if not obvious from their message:

| Phase | When | Purpose |
|-------|------|---------|
| **Investigating** | Something is wrong, cause unknown | Acknowledge the issue, set expectations |
| **Identified** | Root cause found, fix in progress | Explain what's happening, share the plan |
| **Monitoring** | Fix deployed, watching for stability | Confirm the fix, set recovery expectations |
| **Resolved** | Incident is over | Summarize what happened with exact timeframes |

### 3. Gather Incident Details

For any phase, you need:
- **What's affected** — which components/services (use names from context if available)
- **What's the user impact** — what are users experiencing? (errors, slowness, data loss)
- **What's NOT affected** — critical for reducing panic
- **What's being done** — current actions being taken

Additional details by phase:
- **Investigating:** When did it start? Who reported it?
- **Identified:** What's the root cause? What's the fix plan? ETA?
- **Monitoring:** What fix was deployed? How long will monitoring last?
- **Resolved:** Exact start/end times (UTC). What was the root cause? Will there be a postmortem?

### 4. Write the Update

Follow these principles (in priority order):

#### Principle 1: Scope the blast radius immediately
The first sentence should tell users what's affected AND what's not.

**Do:** "REST API requests are returning elevated 5xx errors. The dashboard and webhook delivery are operating normally."
**Don't:** "We are investigating reports of degraded performance for some services."

#### Principle 2: Be specific about user impact
Describe what users are experiencing, not just what's broken internally.

**Do:** "Deployments created between 11:20 and 15:14 UTC may be fail

skills/maintenance/SKILL.md

---
name: maintenance
version: 0.1.0
description: Write planned maintenance announcements for each phase (scheduled, in-progress, completed). Use when the user mentions "maintenance announcement," "scheduled maintenance," "maintenance window," "planned downtime," "maintenance notification," or needs to communicate upcoming planned work to users.
---

# Maintenance

Write maintenance announcements that give users everything they need to prepare, stay informed, and confirm completion.

## When to Use

- "write a maintenance announcement"
- "we have database maintenance next Tuesday"
- "draft a maintenance-in-progress update"
- "announce that the maintenance is done"

## Workflow

### 1. Check for Context

Read `.agents/status-page-context.md` if it exists. Use it for:
- **Component names** — reference the correct service names
- **Maintenance window** — default schedule if one is defined
- **Tone** — match the team's communication style
- **Notification channels** — remind about where to publish

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 the Phase

Ask the user which phase if not obvious:

| Phase | When | Purpose |
|-------|------|---------|
| **Scheduled** | Before the maintenance | Give users time to prepare |
| **In-progress** | Maintenance has started | Confirm it's happening, set expectations |
| **Completed** | Maintenance is done | Confirm everything is back to normal |
| **Cancelled** | Maintenance won't happen | Inform users the planned work is called off |
| **Extended** | Maintenance is running longer than planned | Update the expected end time |

### 3. Gather Details

**For scheduled announcements:**
- What components/services are affected?
- What is the maintenance window? (start time, end time, timezone — always convert to UTC)
- What will users experience? (full downtime, degraded performance, intermittent errors)
- What should users do to prepare? (save work, expect delays, switch regions)
- How far in advance is this being announced?
- Is there a workaround during the maintenance?

**For in-progress updates:**
- Is everything going as planned?
- Has the expected end time changed?
- Any unexpected impact?

**For completed announcements:**
- Did it finish on time?
- Is everything back to normal?
- Any follow-up actions needed from users?
- Were there any unexpected issues during maintenance?

### 4. Write the Announcement

Follow these principles:

#### Principle 1: Lead with what users need to do
The first sentence should tell users whether they need to take action.

**Do:** "Save any uncommitted work in Codespaces before Tuesday 16:00 UTC — we're performing scheduled maintenance that may interrupt active sessions."
**Don't:** "We will be performing scheduled maintenance on our infrastructure."

#### Principle 2: Be specific about the impact
"May experience issues" is not helpful. Tell users exactly what will and won't work.

skills/postmortem/SKILL.md

---
name: postmortem
version: 0.1.0
description: Write blameless postmortems after incidents with timeline, root cause analysis, impact assessment, and action items. Use when the user mentions "postmortem," "post-mortem," "incident review," "root cause analysis," "RCA," "incident retrospective," "what went wrong," or wants to document lessons from a resolved incident.
---

# Postmortem

Write blameless, actionable postmortems that help teams learn from incidents — not assign blame.

## When to Use

- "write a postmortem for yesterday's outage"
- "help me do an RCA for the API incident"
- "we need an incident retrospective"
- After using `incident-communication` to resolve an incident

## Workflow

### 1. Check for Context

Read `.agents/status-page-context.md` if it exists. Use it for:
- **Component names** — reference the correct service names
- **Severity levels** — classify the incident correctly
- **Past patterns** — check if this is a recurring issue
- **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 Audience

Ask the user who will read this postmortem:

| Audience | What to emphasize |
|----------|------------------|
| **Internal (engineering team)** | Deep technical detail, code-level root cause, specific system names |
| **Internal (leadership/cross-functional)** | Business impact, timeline, prevention measures, resource asks |
| **External (customers/public)** | User impact, what was done, what's changing, trust rebuilding |

Default to **internal (engineering team)** if not specified.

### 3. Gather Incident Details

Ask for or extract from conversation:

**Required (postmortem cannot proceed without these):**
- What happened (high-level summary)
- When it started and ended (UTC)
- What was affected (components, users, regions)
- What caused it (root cause, even if preliminary)
- How it was fixed (mitigation steps)

**Important (ask if not provided, mark `[TODO]` if unknown):**
- Who detected it and how (monitoring alert, customer report, internal discovery)
- Timeline of key events (detection, escalation, diagnosis, mitigation, resolution)
- Quantified impact (error rates, affected users/requests, revenue impact)
- Contributing factors beyond the root cause

**Optional (include if available):**
- On-call responders and roles
- Links to relevant logs, dashboards, PRs
- Screenshots or graphs showing the impact

### 4. Write the Postmortem

Use the template below. Fill in what you can from the information provided. Mark unknown sections with `[TODO: description of what's needed]` — never invent details.

### 5. Review Checklist

Before delivering, verify:
- [ ] Blameless language throughout (no "Person X failed to...")
- [ ] Root cause goes deep enough (at least 2 "why"s deep)
- [ ] Every action item has an owner placeholder and priority
- [ ] Timeline has at least 4 entries (detection, identifi

skills/status-page-context/SKILL.md

---
name: status-page-context
version: 0.1.0
description: Create or update the status page context document that all other status page skills reference. Use when setting up status page skills for the first time, or when the user mentions "status page context," "configure status page," "set up incident tone," or wants to define their service components, SLAs, or communication style.
---

# Status Page Context

Create and maintain `.agents/status-page-context.md` — the foundational context document referenced by all other status page skills.

## When to Use

- First time using any status page skill
- "set up my status page context"
- "configure my incident communication style"
- "update my SLA commitments"
- User wants to define components, tone, or escalation paths

## Workflow

### 1. Check for Existing Context

Look for `.agents/status-page-context.md` in the project root.

- **If it exists**: Read it and ask the user what they want to update.
- **If it doesn't exist**: Offer two modes:
  - **Auto-draft**: Scan the codebase for clues (README, config files, status page config, package.json) and pre-fill what you can.
  - **Start from scratch**: Walk through each section interactively.

### 2. Gather Context

For each section below, ask the user to fill in or confirm. Pre-fill from codebase where possible. Do NOT skip sections — each one is used by downstream skills.

### 3. Write the File

Write the completed context to `.agents/status-page-context.md`. Use the template below.

## Context Template

```markdown
# Status Page Context

*Last updated: [date]*

## Service Overview
**Company/Product name:**
**One-liner:**
**Status page URL:**
**Primary audience:** (e.g., developers, enterprise customers, end users)

## Components
List every component shown on your status page.

| Component | Description | Criticality |
|-----------|-------------|-------------|
| | | High / Medium / Low |

## SLA & Uptime Commitments
**Uptime target:** (e.g., 99.9%, 99.95%)
**Response time SLA:** (e.g., acknowledge within 15 min, update every 30 min)
**Maintenance window:** (e.g., Tuesdays 2-4am UTC)
**SLA consequences:** (e.g., credits, contractual obligations)

## Communication Tone
**Style:** (formal / conversational / technical)
**Voice characteristics:** (e.g., calm, transparent, empathetic, no corporate jargon)
**Words to use:**
-
**Words to avoid:**
-
**Example good sentence:**
> "[example that sounds like your brand]"

## Severity Levels
| Level | Criteria | Example |
|-------|----------|---------|
| Critical | Complete service outage or data loss | API returning 500 for all requests |
| Major | Significant degradation affecting most users | Dashboard load times >10s |
| Minor | Limited impact, workaround available | Webhook delays of 2-5 minutes |
| Maintenance | Planned work, no unexpected impact | Scheduled database migration |

## Escalation & Roles
**Incident commander:** (role or person responsible for coordinating response)
**Communications lead:** (who w

skills/status-report/SKILL.md

---
name: status-report
version: 0.1.0
description: Write periodic status reports summarizing overall system health, uptime, incidents, and maintenance. Use when the user mentions "status report," "health report," "uptime report," "weekly status," "monthly report," "system health summary," "reliability report," or wants to publish a regular update on how their services are performing.
---

# 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'

Github ReposUpdated 2d agoRank 70

AionUi

Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!

MCPOPENCLAW

Github ReposUpdated 6mo agoRank 70

activepieces

AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents

OPENCLAW

Github ReposUpdated 6mo agoRank 70

cherry-studio

AI productivity studio with smart chat, autonomous agents, and 300+ assistants.