A production deployment failed or caused errors immediately after release. How would you investigate?

How do you investigate a failed production deployment?

Explains a structured response to a failed production deployment in a .NET application.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would first check what changed and what is failing. I would look at the deployment logs, application startup logs, health checks, error rate, recent configuration changes, migration status, and whether the issue affects all users or one path. Then I would decide whether to rollback, roll forward, disable a feature flag, or fix configuration.

Full answer below

Practice focus

Incident triage, deployment logs, health checks, configuration, migrations, rollback/roll-forward, and communication.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
A failed production deployment needs safe mitigation, focused diagnosis, and clear communication at the same time. Pipeline status alone is not enough to decide whether to retry, roll back, roll forward, or stop the release.
I would first check what changed and what is failing. I would look at the deployment logs, application startup logs, health checks, error rate, recent configuration changes, migration status, and whether the issue affects all users or one path. Then I would decide whether to rollback, roll forward, disable a feature flag, or fix configuration.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
For example, a .NET API may deploy successfully but fail at startup because a required environment variable or Key Vault secret is missing. Another common issue is a migration that succeeded in staging but locks or fails in production. The trade-off is that quick rollback may not be safe if the database changed, so the mitigation must match the failure type.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Immediately redeploying without understanding the failure.
Ignoring configuration and secrets.
Rolling back despite incompatible migration changes.
Not communicating during the incident.

A production deployment failed or caused errors immediately after release. How would you investigate?

Practice focus

Answer path

Why this question matters

Review signals

Coding practice

Follow-up prompts

Continue the section

Tech stacks

Suggest an improvement