Identify the incident session worth capturing
After resolving a production incident, you have a Devin session transcript that captured every diagnostic step, every command run, and every decision made under pressure. That transcript is the raw material for a playbook your on-call team can reuse next time.Not every incident session is playbook material. Look for sessions where Devin followed a clear, repeatable methodology — the kind of incident your team sees regularly:
- Memory leaks — identified the source, applied the fix, verified heap usage post-deploy
- Connection pool exhaustion — traced the root cause, tuned pool settings, added monitoring
- Cascading timeouts — isolated the failing upstream, added circuit breakers, validated recovery
Create the playbook
Open the Devin home page and start a new session. Describe the session you want to turn into a playbook.Paste the incident session link and describe what the playbook should capture. Be specific about the scope of generalization — the playbook should work for the class of incident, not just the one service that broke.If you have multiple resolved incidents of the same type (e.g., two different memory-leak sessions), add them all. Devin identifies common patterns across sessions and produces a more robust playbook.
Test it on the next incident
The real test is whether the playbook works on a different instance of the same class of incident. When the next memory issue surfaces, start a new Devin session, attach the playbook, and point it at the affected service.If the session resolves the incident cleanly, your playbook generalizes well. If it struggles — maybe the leak pattern is different, or the service uses a different database driver — feed that session back into Devin and ask it to improve the playbook. See Fix a Flaky DB Migration Playbook for that workflow.