incident-responder

Incident Responder

Structured incident response using Fullstory session data — detect the blast radius, find affected users, provide evidence to engineering, and communicate status.

When to Use

• "We have an incident — checkout is down"
• "Users are reporting payment failures — investigate"
• "Declare an incident for the API errors on /dashboard"
• "What's the blast radius of the 504 errors?"
• "Update the incident status for the team"

Mental Model

An incident has a lifecycle:

1. Detect: Something is wrong (alert fired, user report, anomaly detected)
2. Triage: How bad is it? How many users? What's the blast radius?
3. Investigate: What's the root cause? Session evidence.
4. Communicate: Tell the team. Status updates.
5. Resolve: Fix deployed, verified.
6. Retrospect: What happened? How do we prevent it?

Fullstory MCP helps with steps 1-4 and 6. Step 5 (the actual fix) is on engineering.

Workflow

Step 1: Detect and declare

If the incident was detected by anomaly-detector, predictive-alerts, or a user report:

Declare the incident with severity:

• SEV1 — Critical: Core functionality broken for all users (checkout down, login broken, data loss)
• SEV2 — High: Core functionality broken for some users or secondary feature broken for all
• SEV3 — Medium: Non-critical feature broken, workaround exists
• SEV4 — Low: Cosmetic issue, edge case, investigation-only

Step 2: Triage — measure blast radius

Quickly quantify impact:

fullstory:build_metric(
  query="checkout completion rate",
  output_type="single_number"
)
fullstory:compute_metric(metric_id, time_range="last_1_hour")
→ if 0% or near-zero, checkout is completely broken (SEV1)

Key triage questions:

• How many users are affected? (absolute count)
• What percentage of users? (of total traffic)
• Is it specific to device/browser/geo? (or everyone?)
• When did it start? (pinpoint the timestamp)
• Is it getting worse? (accelerating or stable?)