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.

Use free fullstory:discover_groups and fullstory:get_opportunity_stats for live signals. Discovery accepts one scope at a time (page_id, domain, app_name, segment_id, or funnel_id); use a segment for device/user filters and the live schema for time ranges. Use computed metrics for exact custom windows.

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)