How I Taught My Incident Alerts to Say "This Broke 3 Minutes After Your Last Deploy"

You're staring at a P95 latency spike.

The alert says: "Database pool exhausted. P95: 2847ms."You know what broke. You don't know why.
So you open your git log, check when the spike started, scroll through commits, and try to figure out what changed in the 10 minutes before everything went sideways.
That archaeology takes 20 minutes on a good day. At 2am it takes longer.

The Problem with Context-Free Alerts
Most incident alerts are great at telling you the “what”. None of them tell you the “when” in relation to your codebase.
The question every engineer asks during an incident isn't "what is the P95?" — they already know that. It's "Did we just deploy something?"

The Insight: Incidents Have a Deployment Shadow
The way I see it, the majority of production incidents fall into one of two categories:
• Infrastructure events — upstream dependency failure, Redis outage, traffic spike
• Deployment shadows — something changed in the last deploy that didn't show up in testing

For category 2, the fastest path to resolution is knowing exactly what changed and when — down to the commit level.
If your alert says:
Database pool exhausted (P95: 2847ms)
Recent deployments before incident:
3m ago — a1b2c3d: "Fix checkout query isolation level" (John, +12/-3)
1 recent commit touched database/query files
You've just saved 20 minutes of log archaeology.

How to Build It
The implementation is simpler than it sounds. Three components:
• A commit store — Redis sorted set, scored by timestamp
• A GitHub webhook — receives push events, stores commits
• An incident correlator — maps incident start time to nearby commits

The Commit Store
def store_commit(tenant_id, sha, message, author, timestamp, files_changed):
key = f"orchestrator:commits:{tenant_id}"
redis.zadd(key, {entry: timestamp})
redis.expire(key, 86400 * 7) # 7 day TTL
A Redis sorted set gives you O(log N) insertion and O(log N + K) range queries — perfect for "give me commits in the 10 minutes before this timestamp."

The GitHub Webhook
@app.post("/commits/webhook")
async def github_webhook(request: Request):
body = await request.json()
for commit in body.get("commits", []):
store_commit(...)

Injecting Context into AI Diagnosis
Without commit context, Claude sees raw metrics. With commit context, Claude sees the metrics AND what changed 3 minutes before the incident — shifting the diagnosis from "likely database connection issue" to "checkout query isolation level change likely caused connection pool exhaustion."
That's a different quality of diagnosis entirely.

What the WhatsApp Message Looks Like
⚠️ Action Recommended
Service: Payment API
Issue: Database pool exhausted — P95 2.8s
Likely cause: Checkout query isolation level change
(commit a1b2c3d, 3m ago)
Confidence: 87%
👉 Approve fix: [link]
Nothing will run without your approval.

Three Setup Options
• GitHub webhook (recommended) — POST /commits/webhook with header X-AlertEngine-Tenant-ID
• Manual push from CI — curl from your GitHub Actions workflow
• GitHub API polling — set GITHUB_TOKEN and GITHUB_REPO, AlertEngine fetches automatically

The Broader Pattern
This feature is an instance of a broader pattern: enrich your incident context with everything that changed recently, not just the metrics at the moment of failure.
Future extensions of the same idea:
• Feature flag changes in the 10 minutes before an incident
• Infrastructure changes (Terraform applies, Docker image updates)
• Database migration executions
• Config changes

The alert that says, "Here's what broke, here's what changed right before it broke, here's the fix"—that's the alert worth building for.

─────────────────────────────────────────
This is now live in FastAPI AlertEngine as commit_context.py.
GitHub: github.com/Tandem-Media/fastapi-alertengine
Docs: tandem-media.github.io/fastapi-alertengine/
pip install fastapi-alertengine