INCIDENT RESPONSE
Incident Resolution
The point in the incident lifecycle where the service is restored to full functionality for the customer.
Resolution
The point in the incident lifecycle where the service is restored to full functionality for the customer.
Fix vs. Resolve
In Incident Management, "Resolved" does not always mean "Fixed."
- Resolved means the patient is stable (Customer can use the site).
- Fixed means the root cause is gone (Bug is patched).
Often, you resolve an incident via a workaround (e.g., restarting the server), and fix it the next day (e.g., patching the memory leak).
ExPayment Gateway Timeout
"Checkout failing due to payment gateway timeouts. Resolution: Temporarily disabled Save Payment feature and switched to fallback provider in 12 minutes. Permanent fix implemented 2 days later to add retry logic and circuit breaker."
Impact
Saved $200K in revenue during peak shopping period
Resolution
Fallback architecture prevented single point of failure
Why Resolution Matters
This is the primary goal of Incident Response.
Ending the incident explicitly stops the MTTR clock.
Common Pitfalls
Closing incident without verifying the fix
Always test in production or a staging environment that mirrors production before declaring resolution.
Confusing workaround with resolution
Document workarounds as temporary. Create follow-up tickets for permanent fixes and track completion.
Related Terms
Frequently Asked Questions
What is the difference between resolution and mitigation?
Resolution restores service to normal operation. Mitigation reduces impact but may not fully restore service. A workaround is a temporary mitigation.
When should you declare an incident resolved?
When service is verified as functional for end users and the incident commander confirms resolution. Always verify in production before declaring.
What if an incident reoccurs after resolution?
Create a new incident with a link to the previous one. Track "recurrence rate" as a metric. Frequent recurrences indicate incomplete fixes.