When someone says their website is broken, the first question is always: broken how?
Sometimes it’s obvious. The site won’t load. Checkout is failing. Emails have stopped sending. But more often, it’s vaguer. “Something isn’t working right.” “Users are complaining.” “It was fine yesterday.”
That first hour matters. Not because you’ll fix everything immediately, but because you’ll understand what’s actually wrong. And that shapes everything that follows.
Here’s what I look at first.
Logs and console errors
This is where I start. Always.
Server logs tell you what’s failing behind the scenes. PHP errors. Database connection issues. Timeouts. Memory limits being hit. Things the user never sees but that explain why something isn’t working.
The browser console shows client-side problems. JavaScript errors. Failed API calls. Blocked resources. Mixed content warnings.
Most of the time, the logs point directly at the problem. A plugin throwing errors. A missing file. A broken API endpoint. You’re not guessing anymore. You’re reading what the system is telling you.
If the logs are clean, that’s useful too. It means the problem is probably elsewhere. User-facing. Integration-related. Something the server isn’t catching.
But if there are errors, you deal with those first. Everything else is noise until the obvious problems are cleared.
Integrations and webhooks
Integrations are fragile by nature.
They depend on external systems. APIs change. Authentication expires. Endpoints get updated without warning. A webhook that was working fine last week might be silently failing now.
I check webhook logs next. Most platforms keep a record of what’s being sent and whether it succeeded. Stripe, PayPal, Mailchimp, whatever’s connected. If webhooks are failing, you’ll see it there.
Common culprits: expired API keys, IP whitelisting changes, SSL certificate issues, rate limits being hit.
The tricky part with integrations is they often fail quietly. The website keeps running. Users don’t see an error. But data stops syncing. Emails don’t send. Payments process but don’t update the system.
By the time someone notices, the problem has been happening for a while.
Recent changes
This one’s straightforward but often overlooked.
What changed recently?
Plugin updates. Theme updates. Server migrations. DNS changes. New features deployed. Even small tweaks to settings.
If something broke yesterday and a plugin updated two days ago, that’s your starting point.
The problem is, people don’t always know what changed. Auto-updates run in the background. Hosting providers make server adjustments. Someone on the team might have tested something and forgotten to mention it.
I check update logs. Git commits if version control exists. Server change logs if the host provides them. Anything that shows activity around the time the problem started.
Most issues trace back to something that changed. The question is whether you can find out what.
Payment or email systems
These two systems cause more panic than anything else.
Payments failing means lost revenue. Emails not sending means broken user journeys. Both feel urgent because they directly affect the business.
For payments, I check the gateway first. Stripe dashboard. PayPal logs. Whatever processor is being used. Look for declined transactions, failed webhooks, or API errors.
Then I check the site’s payment flow. Is the order being created? Is the payment being captured? Is the confirmation triggering correctly?
Sometimes the payment goes through fine but the site doesn’t register it. That’s usually a webhook problem or a database write failure.
For emails, I check whether they’re being sent or just not arriving. SMTP logs. Email service dashboards. Spam folders. SPF and DKIM records.
Email problems often come down to configuration. Wrong SMTP credentials. Deliverability issues. Hosting provider blocking outbound mail. The email system works, but something in the chain is stopping delivery.
User journey failures
Sometimes the site isn’t technically broken. It’s just not doing what users expect.
A form submits but doesn’t show a confirmation. A login works but redirects to the wrong page. A membership gives access to the wrong content.
These problems don’t show up in logs. The system is working as coded. It’s just coded wrong, or the logic has drifted from what was intended.
I walk through the user journey myself. Sign up. Log in. Make a purchase. Submit a form. Whatever the reported issue is, I replicate it.
That usually reveals where the breakdown is happening. A redirect that’s pointing to the wrong URL. A role assignment that’s misconfigured. A conditional logic rule that’s backwards.
Fixing these problems is often quick once you’ve found them. The hard part is knowing where to look.
Most problems reveal themselves quickly if you know where to look
The first hour isn’t about fixing everything. It’s about understanding what’s broken and why.
Once you know that, the path forward is usually clear. You’re not guessing. You’re not randomly trying things. You’re working from evidence.
Logs tell you what’s failing. Integrations tell you what’s disconnected. Recent changes tell you what triggered it. Payment and email systems tell you what’s urgent. User journeys tell you what’s frustrating people.
Most of the time, one of those five areas holds the answer.
And when you find it, the rest is just execution.