You visit your company website and instead of your offer, you see a blank screen, an error message, or a page loading endlessly. In an online shop, the situation can be less obvious. The homepage works, but customers cannot add products to the cart, proceed to checkout, or complete an order.
In this situation, the priority is to quickly establish what exactly stopped working, when the problem started, and whether anything changed right beforehand. These three pieces of information often cut troubleshooting time far more than random fix attempts.
Use the first 15 minutes primarily to narrow down the cause and limit the fallout of the outage.
First, confirm what is actually broken
“The website is down” can mean completely different things. The domain might not open at all. The site might display an error. The homepage might load fine while contact forms fail. In an online store, users might browse products smoothly, only hitting an error at checkout.
That is why the first step is to test the site from another device and a different internet connection. The easiest way is to open it on your phone with Wi-Fi turned off. Check several core pages and carry out the primary action the site exists to deliver.
If you run a shop, add a product to the cart and proceed to checkout. If your site generates leads, open and test the contact form. If users log in to a system, test the login flow.
This matters because a working homepage does not mean your sales are working.
Check if the issue affects all users
If the site works on mobile but fails on your computer, the issue may be tied to your local network, browser cache, or stored data. If it fails regardless of the device and connection, you can move forward.
It is also worth checking company email on the same domain. If both your website and email stopped working at the same time, the culprit is likely the domain or DNS settings, not the application itself.
Check your hosting provider's dashboard and status page as well. A couple of minutes is all it takes to rule out an infrastructure outage with your host.
Note down exactly what you see
An error message contains vital diagnostic clues. Do not dismiss it, and do not limit your support ticket to “the site crashed.”
Take a screenshot. Note down the exact URL where the issue occurred, the time, and the action taken right before the error appeared.
A message stating “at 14:37, clicking Pay triggered a 500 error” is infinitely more useful to an engineer than “the shop has been down for a while.”
If the issue is intermittent, mention that too. A bug appearing on every fifth attempt points to an entirely different cause than an outright service outage.
Check what happened right before the breakdown
One of the first questions during troubleshooting should always be: what changed right before the issue began?
Did someone update the website? Was a new plugin installed? Did a developer deploy a release? Were changes made to hosting, domain, or email settings? Did an ad campaign launch, bringing an unexpected surge in traffic?
For an online store, also review changes related to payments, shipping, warehouse integrations, ERP systems, or external APIs.
If a site ran without issues for months and broke minutes after an update, that is the most critical lead for whoever steps in to troubleshoot.
Not every outage looks like an outage
The most obvious scenario is a completely inaccessible website. For a business, however, a far more dangerous situation is when the site looks fine on the surface, but a core sales flow has quietly broken down.
A contact form might display a success message even though emails never reach your inbox. A customer might pay for an order, but payment confirmation never gets sent back to the store. Orders might land in WooCommerce without syncing downstream. A coupon code might stop working. Inventory counts might stop updating.
That is why during an incident, you need to check not just uptime, but the critical path directly driving your revenue.
If you run an online shop, check recent orders
In e-commerce, the order list is one of the very first places to inspect.
If your shop normally processes several orders an hour and none have arrived for two hours, it does not guarantee a breakdown, but it is an immediate red flag.
Check whether new orders are coming in, what statuses they carry, and whether pending or abandoned payments are piling up. If you use a payment gateway, log into its dashboard directly.
You might discover that payments process successfully on the gateway's side, but the shop never receives the webhook callback. That points to a completely different issue than an outright gateway outage.
On a service website, the equivalent of an order is usually a contact form submission, a booking, or a lead enquiry.
Send a test enquiry and trace the entire flow. It is not enough to see “message sent successfully.” Confirm that the submission actually lands in the right mailbox, your CRM, or your lead management platform.
If your ads are still driving traffic to the site while your forms have been dropping leads for hours, you are burning ad spend on a broken sales funnel.
Check if the problem started after an update
In WordPress and WooCommerce, a common cause of downtime is a conflict following an update to a plugin, theme, core WordPress, or the PHP version.
This does not mean you should immediately disable all plugins. First, verify whether an update actually took place around the time the issue started.
If the outage began right after a specific change, reviewing and rolling back that exact change is much safer than modifying additional parts of the site.
Do not restore a backup right away
Backups provide peace of mind, but restoring one should not be your knee-jerk reaction.
If the root cause lies in your domain, SSL certificate, hosting server, or an external API, a backup will not fix it. What it can do, however, is roll back any data captured since that backup was created.
In an online shop, that means potentially losing recent orders, customer accounts, and stock updates. On a service site, you could lose leads, bookings, or newly published content.
Before restoring a backup, you need to know exactly when it was taken and what live data will be overwritten.
Do not attempt multiple fixes at once
During an incident, it is easy to panic and try everything in rapid succession: deactivate a plugin, tweak a setting, restart a service, restore a file, and check if it worked.
The problem comes when multiple changes happen at once. Even if the site recovers, you will not know what actually caused the outage or what fixed it. The next time it breaks, you will be back to square one.
Effective troubleshooting is about isolating variables. First identify the architectural layer responsible, then pinpoint the root cause, and only then apply the smallest possible change needed to restore functionality.
When to pause your ads
If you run paid campaigns, deciding whether to pause them depends on the scope of the incident.
If the site is completely unreachable, continuing to spend budget on paid traffic makes no sense. The same goes if the checkout, contact form, or conversion goal is down.
However, you do not always need to pause everything. If the problem is isolated to one section of the site, simply pause the campaigns pointing to the broken landing pages or features.
Keep this in mind especially if your ad spend is high. A technical fix might take an hour, but during that hour, active campaigns will keep draining your budget.
Once the site is back, make sure sales are back too
The moment the site loads again is not necessarily the end of the incident.
After a fix, walk through the critical path again. In an online store, add an item to the cart, reach checkout, and place a test payment. On a corporate website, submit a form. In a web app, log in and perform a core operation.
It is equally important to inspect what happened during the downtime. Were there partial orders requiring manual handling? Did payments process without generating an order record? Are enquiries stuck in external queues? Does an integration need to re-sync dropped data?
Restoring site uptime and cleaning up the fallout are two separate steps.
What you should achieve in the first 15 minutes
After the first quarter of an hour, you may not know the exact line of code at fault. But you should know far more than when you started.
Whether the issue affects the entire site or a single feature. Whether users can still place orders or send enquiries. When the first error occurred. Whether an update or deployment happened beforehand. Whether the issue affects all users. Whether paid ads need to be paused. And who holds the access credentials required for in-depth diagnostics.
Based on this, you can make an informed decision on whether the issue can be fixed quickly in-house or requires technical support.
Most outage time is lost before the outage even starts
It sounds counterintuitive, but your recovery time often hinges on preparations that should have happened long before anything broke.
If an outage forces you to scramble to find hosting logins, locate domain managers, track down gateway accounts, and locate backups, the first half hour is wasted before troubleshooting even begins.
The same applies to monitoring. If your only notification of downtime is an angry phone call from a customer, you do not even know when the outage actually started.
Effective monitoring should catch far more than zero server response. Depending on the system, it should track application errors, SSL validity, response latency, and critical sales conversion paths.
When to put ongoing technical support in place
If your website or store drives revenue and customer acquisition, incident response should be established well in advance.
It is not just about having someone who knows how to fix a site. It is about who receives the alerts, who holds the necessary credentials, what response times are guaranteed, and what happens outside normal working hours.
At DOCK, we maintain websites, online shops, and web applications built on WordPress, WooCommerce, PrestaShop, Laravel, and other stacks. Before onboarding, we gather necessary credentials, map out the environment, and establish clear response procedures. That way, when an issue arises, we never waste time asking where the server lives or who has the password.
If your website is down right now, we can assess the issue and outline the next steps. If it is currently running smoothly but is vital to your sales, set up an incident response process before your first critical failure hits.
