Every team eventually encounters an "oh no" spike. Here is how we structure a war room so the meeting ends with clarity instead of blame.

Before the meeting

Before diving in, remind teams how Stack Dyno supports this stage so the bullets feel connected.

• Pull the Stack Dyno anomaly alert and note the exact services/projects involved.
• Capture the timeline: when spend started rising, when it was detected, who was paged.
• Export the relevant charts (/spending, /alerts, /kubernetes) so you have an offline copy.

During the review

1. Reconstruct the change – which deploy, script, or workload caused the spike?
2. Quantify impact – share the delta in dollars plus any ancillary effects (quota, latency, churn risk).
3. Plan the fix – rightsize, pause, roll back, or adjust commitments. Document owner + ETA.

- Owner: `@platform-oncall`
- Fix: Pause batch importer job in `analytics-prod`
- ETA: 2024-09-06 18:00 PT
- Follow-up: add alert for >25% ingestion growth week-over-week

After the call

Before diving in, tie the actions to a clear outcome instead of a generic task list.

• Send a recap with screenshots, the agreed plan, and open questions.
• Automate any learnings: if a missing label slowed you down, make it part of your CI policy.
• Update Stack Dyno saved views or tags so the next spike is even faster to triage.

War rooms become less scary when the data is already organized. Stack Dyno keeps the narrative straight so you can focus on shipping the fix.

---