incident-response

Guides solo production incident triage across Render, Cloudflare, MongoDB Atlas, Telegram, and Sentry.

Updated Aug 5, 2026
One-click install
npx skills add https://github.com/amirbiron/claude-skills --skill incident-response-amirbiron
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: incident-response
Source: https://github.com/amirbiron/claude-skills/tree/main/drafts/incident-response
Command: npx skills add https://github.com/amirbiron/claude-skills --skill incident-response-amirbiron

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? When a client's live site, bot, or service goes down and you are handling it alone — often from a phone — generic incident-response playbooks waste the critical first minutes on org-style role assignments and status meetings. This Skill gives a single operator a concrete diagnostic order, ready-to-send client message templates in plain Hebrew, and a one-paragraph postmortem format. ## Core Features & Use Cases - Prioritized diagnostic sequence: Check what changed in the last hour first, then Render, Cloudflare Pages, MongoDB Atlas, the Telegram webhook, and Sentry — ordered by probability, with platform-specific traps like stale last_error_message values and free-tier cold starts. - Client communication templates: Three pre-written messages (first response within 10 minutes, status update, closure) that promise an update time rather than a fix time, in jargon-free language. - Severity triage and rollback safety: Three severity levels instead of SEV1-4, plus a data-touch check before rolling back a deploy so a migration is not reverted blindly. - Use Case: A client messages that their site is down at 2 AM. The Skill tells you to send the first holding message immediately, then walk the diagnostic ladder — recent changes, Render status, Cloudflare deploy, Atlas connections — and close with a one-paragraph postmortem. ## Quick Start Use the incident-response skill to help me handle a production outage my client just reported on their live site.

Frequently Asked Questions about incident-response

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I handle a production outage alone as a solo developer?

Send the client a first message within 10 minutes promising a next update time, then diagnose in probability order: what changed in the last hour, Render status, Cloudflare Pages deploy, MongoDB Atlas limits, Telegram webhook, and Sentry last. Close with a one-paragraph postmortem noting what changed to prevent recurrence.

What should I check first when a site goes down after a deploy?

Check what changed in the last hour first — a push, merge, environment variable change, or CMS update. Before rolling back, verify whether the change touched data: code rollbacks do not undo migrations, and running old code against a new schema can cause more damage.

Why does Telegram getWebhookInfo show an old error message?

The last_error_message field is not cleared after the problem is fixed, so a week-old error can look like the current cause. Compare last_error_date to when the incident actually started, and also check the url field for an overwritten webhook and pending_update_count for accumulating failures.

When should I not use an incident-response workflow?

Do not use it for a bug you are investigating calmly with nothing live at stake — that is ordinary debugging. Also skip it before a deploy when nothing has broken yet; that scenario belongs to a pre-deploy checklist instead.

What should I tell a client during an outage before I know the cause?

Send a short message within 10 minutes acknowledging the issue and promising a specific next update time, not a fix estimate. Avoid jargon like server or deploy, never claim you found the cause before verifying it, and apologize for a missed update time rather than for the outage itself.