Start by preserving the evidence
Save the current project, deployment identifier, exact error text, and last known-good version before changing anything. A screenshot helps, but a reproducible sequence and protected log entry are stronger evidence. Never include passwords, private keys, recovery codes, or live customer data.
Describe the behavior, not your theory
Write the steps a user takes, what should happen, and what actually happens. Note whether it affects every account, one role, one device, one route, or only production. This separates symptoms from assumptions and gives the investigation a stable target.
Map the layers involved
List the builder, repository, framework, hosting provider, database, authentication provider, payment service, email provider, DNS owner, and any APIs on the failing path. You do not need administrator access to all of them; you need to know which systems exist.
Test the smallest dependable path
Use a safe test account and non-production mode where available. Confirm each boundary separately: browser request, server handler, provider response, database change, background event, and final user-visible state. A polished success screen is not proof that the work completed.
Decide repair, refactor, or rebuild
Repair an isolated fault. Refactor when working behavior is too fragile to change safely. Replace a subsystem when its core assumptions are unreliable. Rebuild the project only when access, ownership, security, or total repair cost makes continued patching irresponsible.
Create a handoff that survives the next change
Record the cause, files or settings changed, safe test steps, deployment notes, and remaining risks. Add an automated or repeatable regression check around the repaired behavior. The goal is not only to make today’s error disappear but to keep it from silently returning.