Start with scope and time
Record when the issue started, which journey is affected, whether the failure is universal or segmented, and the last known release/configuration change. Avoid restarting everything before capturing evidence.
Collect the smallest useful evidence set
- request or incident reference
- HTTP status and response class
- application error class
- database latency and active work
- queue age and retry counts
- provider response category
Reduce blast radius before recovery
Disable or defer optional work when possible. Do not bypass payment verification, inventory correctness or authentication merely to make the interface appear healthy.
Repair once, then verify the business state
Use idempotent replay or reconciliation for recoverable work. After technical recovery, verify the transaction state—order, payment, shipment or inventory—not only the HTTP response.
Deployment-specific configuration wins.
Use these patterns to structure a Thonem project, then verify the exact routes, providers, secrets, queues and infrastructure of the deployed environment before changing production.