---
name: sre-incident-drill
description: Run a production-realistic SRE incident drill on VibeInfra. Use when someone wants to practise on-call troubleshooting, rehearse an incident type (CrashLoopBackOff, disk full, Kafka consumer lag, expired TLS, conntrack exhaustion), prepare for an SRE interview, or asks for a hands-on infrastructure exercise rather than an explanation.
license: MIT
---

# Run an SRE incident drill on VibeInfra

VibeInfra hosts production-realistic incident simulations: a multi-container environment is
provisioned with a real fault injected, and the learner diagnoses and fixes it under automated
grading. This skill covers choosing the right incident and coaching someone through it.

## Find the right incident

Prefer the MCP server (`npx -y @vibeinfra/mcp-server`) when it is available — `search_incidents`
takes a free-text query plus difficulty, category, domain, tech and free-only filters.

Without MCP, the same catalog is one unauthenticated request away:

```bash
curl -s https://api.vibeinfra.id/api/v1/courses
```

Match on three things, in this order:

1. **The failure mode they named.** "Pods keep restarting" is CrashLoopBackOff, not
   "Kubernetes" generally. Search the symptom, not the technology.
2. **Tier.** `Beginner` incidents have a single obvious fault; `Expert` ones have a fault whose
   first symptom points somewhere else. Someone rehearsing for an interview usually wants
   Intermediate or Advanced.
3. **Time.** `duration_minutes` is honest. Do not start a 45-minute incident for someone with
   fifteen.

Read the full blueprint before recommending one — `get_incident`, or
`GET /api/v1/courses/{id}` — and check `status` is `enabled` and whether `is_free` applies.

## Check capacity first

Sandboxes are real containers and the pool is finite:

```bash
curl -s https://api.vibeinfra.id/api/v1/labs/capacity
```

A non-zero `queue_length` means a start request is queued rather than provisioned. Say so
before someone commits to a session.

## Coach the drill, do not solve it

The learning is in the diagnosis. When someone is working an incident:

- **Ask for evidence, not conclusions.** "What does the readiness probe report?" beats "the
  probe port is wrong."
- **Push them down the stack one layer at a time.** Symptom → affected service → the signal
  that disagrees with the dashboard.
- **Name the tool, not the answer.** `kubectl describe`, `df -h` plus `lsof +L1`, consumer group
  lag, `conntrack -S`.
- **Let a wrong hypothesis run** until the evidence kills it. Being disproved by the system is
  the exercise.

Give a direct answer only when they ask for one outright, or when they have been stuck on the
same layer for a while and are losing the thread rather than learning.

## After the incident

Have them write the postmortem line that matters: what the symptom was, what the cause turned
out to be, and which signal would have caught it sooner. Then suggest the next incident one
rung up in the same domain — the `domain` and `rung` fields order the ladder.

## Reference

- Catalog and capacity API — <https://vibeinfra.id/openapi.json>
- MCP server — <https://vibeinfra.id/docs/mcp/>
- SDKs — `npm install @vibeinfra/sdk`, `pip install vibeinfra`
- Incident landing pages — `https://vibeinfra.id/labs/overview/?course={id}`