incident-response

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

Updated Aug 5, 2026
Ready to run
npx skills add https://github.com/amirbiron/claude-skills --skill incident-response-amirbiron
πŸ’¬ Prompt for ChatGPT / Claude Chatβ–Ό
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.