A serious bug is harder to handle when you are the person building the feature, answering questions and checking the backend. I want a clear process for that moment, so urgency doesn't turn into random editing.
The first job is to understand the impact and stop the problem getting worse.
I judge the impact before the size of the error
A long error message may come from something minor. A quiet mistake with permissions, payment state or stored data can be much more serious.
I need to ask which users and workflows are affected, whether data is exposed or damaged, and whether leaving the feature running will cause more harm.
I contain the problem where appropriate
Depending on the evidence, that might mean disabling the affected feature, pausing a process, restricting access or rolling back a recent release.
I need to consider dependencies and data changes before a rollback too. An older application version may not be compatible with a new database change. Containment should reduce harm rather than create another incident.
I preserve useful evidence
Record the time, affected action, error, request or transaction reference, deployment version and recent changes. Keep relevant logs before overwriting them.
I should protect private information and avoid copying sensitive data into casual notes. Enough context to investigate is the goal.
I describe the failure clearly
“Profiles are broken” is broad. “Users can read their profile, but updates return 403 after the policy change” gives me something more specific to check.
That is an example, not a diagnosis of every 403. I still need to verify what the response and logs show.
I check recent changes and reproduce safely
Review deployments, dependencies, environment settings, database migrations, DNS and provider configuration. A recent change is a lead, not proof.
Use test accounts and safe environments where possible. I don't want to create a real payment or delete real data just to reproduce an error.
I follow the failing request
Did the interface send the correct input? Did the request leave the browser? Is the session valid? Does the identity have permission? What happened in the backend, database or external service?
Those checks help me avoid turning a database problem into an unnecessary frontend rewrite.
I keep the fix focused and verify it
Once the cause is supported by evidence, make the smallest understandable correction. Unrelated refactoring can wait.
Test the original failure, the normal path, related permissions, a second account and retries where they matter. If I rolled back, check the restored behaviour too.
I communicate what I know
A status message should say what is affected and what is currently known. I shouldn't promise a repair time I can't support or announce a cause before confirming it.
After recovery, write down the impact, cause, containment, fix and what could prevent it happening again. A useful test or alert should come from the actual failure.
I prepare a recovery path before I need it
For important data, I want to understand the backup and restore process and verify it in advance. Basic monitoring should also help me notice failures in critical requests and workflows.
Working alone doesn't mean I need to rely on panic. I want a process I can follow quickly: assess, contain, preserve evidence, investigate, fix, verify and learn from the result.
An incident note with a separate recovery decision
During a serious bug, restoring the main journey and identifying the complete root cause may be different tasks. This blank record keeps that distinction visible:
First observed time: Affected journey: Known scope and source of that estimate: What still works: Reproduction using test data: Current user-facing message: Recent deployment or configuration change: Immediate containment option: Risk of that option: Previous working version and rollback route: Recovery action actually taken: Check that confirms the journey is restored: Root cause: confirmed / still under investigation Evidence supporting the cause: Regression check to keep: Follow-up owner and next action:
For example, “reverted the latest deployment and the test journey works again” describes recovery. It does not by itself identify the exact defect in that deployment. Keep the investigation open until the cause is supported.
If a payment or data write has an unknown outcome, preserve its reference and investigate before repeating it. A timeout does not show that nothing happened. Do not clear records or disable access controls merely to make an error disappear.
In a public incident note, share the affected feature, current status and next update without exposing private records or speculation as fact. When no users have been confirmed affected, say that the scope is still being checked.