Lesson 29 of 30

Incident Response Tied to Deploys

Q: An error-rate alert fires shortly after a deploy went out. Walk me through how you'd figure out whether the deploy caused it, and what you'd do about it.

A strong answer covers: Describes correlating the alert timestamp with recent deploy timestamps — ideally via deploy markers already visible in the monitoring tool; Prioritizes fast rollback as the first response action once the correlation looks strong, rather than root-causing before acting; Acknowledges correlation isn't certainty but is a strong enough signal to act on immediately; Understands rollback speed depends on the deployment strategy in place (e.g. blue-green/canary traffic flip vs. a full redeploy).

When an alert fires, the first question is always 'was this us?' If your monitoring shows deploy markers next to the error graph, you already know the answer.

15 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

No quiz for this one — it's a practical topic

This topic is about judgment and practical tradeoffs more than a single right answer — a mock interview is the better way to test yourself on it.

Be interviewed on this →

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on Incident Response Tied to Deploys

What interviewers actually ask about this, and what a strong answer has to cover.

An error-rate alert fires shortly after a deploy went out. Walk me through how you'd figure out whether the deploy caused it, and what you'd do about it.

A strong answer covers

Describes correlating the alert timestamp with recent deploy timestamps — ideally via deploy markers already visible in the monitoring tool
Prioritizes fast rollback as the first response action once the correlation looks strong, rather than root-causing before acting
Acknowledges correlation isn't certainty but is a strong enough signal to act on immediately
Understands rollback speed depends on the deployment strategy in place (e.g. blue-green/canary traffic flip vs. a full redeploy)

Likely follow-ups

What if there's no deploy marker and you just have a deploy log in a separate tool — how does that change your first five minutes?
Suppose you roll back and the error rate doesn't drop. What does that tell you, and what would you check next?
How would you convince a team that's currently doing neither deploy markers nor fast rollback to invest in both?

Practice these with the AI interviewer →

The plain-language idea

An error-rate alert fires. The first question anyone on call asks is "was this us?" — did a recent deploy cause this, or is it something external (a dependency outage, a traffic spike, a bad actor)? Answering that fast matters more than it sounds: if it was a deploy, the fix is often a rollback that takes two minutes; if it wasn't, a rollback wastes those two minutes and the real cause is still live.

The way you answer it fast is by making deploys visible inside the same tool that shows you errors — a vertical line on the error-rate graph marking exactly when each deploy went out. Without that, "was this us" means someone manually cross-referencing a deploy log against a timestamp, during an active incident, which is exactly when you have the least attention to spare for detective work.

See it in a real thing: a deploy marker as a pipeline step

A deploy job that also tells your monitoring tool it happened:

deploy:
  needs: build
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v4
    - run: pnpm build
    - name: Deploy
      run: vercel deploy --prod --token=$VERCEL_TOKEN

    - name: Record deploy marker in Sentry
      run: |
        curl -sf -X POST "https://sentry.io/api/0/organizations/$SENTRY_ORG/releases/" \
          -H "Authorization: Bearer $SENTRY_AUTH_TOKEN" \
          -H "Content-Type: application/json" \
          -d "{\"version\": \"${{ github.sha }}\", \"projects\": [\"praxis\"], \"dateReleased\": \"$(date -u +%Y-%m-%dT%H:%M:%SZ)\"}"

Now Sentry's (or Datadog's, or whatever the monitoring tool is) error-rate dashboard shows a thin vertical line at 2026-09-09T14:17:00Z labeled with that commit SHA. If the error spike's leading edge sits right on that line, that's not a coincidence to investigate — that's your answer.

What people usually miss

Watch out

Correlation here is a strong prior, not proof — but it's strong enough to act on. A spike starting within seconds of a deploy marker is overwhelmingly more likely to be caused by that deploy than to be an unrelated coincidence. Waiting for certainty before acting costs real time; act on the correlation, confirm afterward.
"Rollback" doesn't have to mean a git revert and a full redeploy. If the release went out through a blue-green or canary setup, "rolling back" is often just flipping traffic back to the previous, still-running version — seconds, not minutes. This is exactly why the deployment strategy chosen earlier in the pipeline determines how fast incident response can actually move.
No deploy markers means every incident starts from zero. Teams that skip this step end up doing the timestamp cross-referencing manually, in a second tool, mid-outage — reconstructing exactly the information a five-line CI step could have handed them automatically.

The genealogy: this is the rollback lesson, under pressure

Rolling back to the last known-good deploy as fast as possible, before fully understanding why the new one broke things, is precisely the technique the rollbacks lesson covers. Incident response doesn't introduce a new tool — it's that same fast-revert instinct, just now with a live outage supplying the urgency to actually use it immediately instead of debating it.