Delivery team online — 09:30–19:00 IST
Troubleshooting · Website, product and conversion

Your site went down: what to do in the first hour

Work through an outage in order: confirm it, locate the layer that failed, stop the bleeding and avoid the moves that extend the downtime.

The first hour decides how long the outage lasts

A customer sends a screenshot. The site shows an error or a blank page or a warning about the connection not being private. The instinct is to start changing things. That instinct is why most outages last longer than they need to. Changes made blind destroy the evidence of what failed and occasionally create a second fault on top of the first.

An outage has layers. The domain, the name servers, the hosting, the application and the certificate. Each layer fails differently and each shows a different symptom. The first hour is spent identifying which layer broke and limiting the commercial damage while it is fixed.

What an outage costs and what nobody covers

Emergency recovery is usually outside the scope of a maintenance arrangement. Most retainers cover routine custody and bill incident work by the hour, so read that clause now rather than during the incident. Lost orders are not recoverable and nor is ad spend that ran against a dead landing page. A restore from backup silently discards every content change made since that backup was taken. Any emergency service fee attracts GST at 18%.

The cost that catches businesses out is credentials. If nobody in the room has the hosting login, the domain registrar login and access to the email address those accounts recover to, the first hour goes on finding a former supplier rather than on fixing a site. That hour is the most expensive one in the whole incident and it is entirely avoidable in advance.

When you should not touch it yourself

Stop if you suspect the site was compromised. Defacement, unknown administrator accounts, redirects to another domain or files you do not recognise all point that way. Poking at a compromised system overwrites logs and makes a clean recovery harder. The same applies if your site stores customer data or handles payments, because an incident there is no longer only a technical matter.

The reverse case is worth stating plainly. A brochure site down for an hour on a Sunday is an irritation and nothing more. Do not pay emergency rates for it. A store in the middle of a sale campaign needs the holding page up within minutes.

The sequence that actually works

Confirm the outage is real and general. Load the site on mobile data as well as office wifi and use an external checker. A site that works everywhere except your office is a local network problem and not an outage. Then read the symptom instead of skipping past it. A server error points at the application or the server. A database connection error points at the database or at hosting resources. A certificate warning points at an expired or misinstalled certificate. A registrar parking page points at a lapsed domain renewal or an expired card on the account.

Check the hosting provider status page and your own billing. An unpaid invoice is a common and embarrassing cause. Then ask what changed in the last day. A plugin or theme update, a DNS edit, a new script added by a marketing tool, a card that expired. Outages rarely arrive from nowhere.

While that is happening, stop the bleeding. Pause paid campaigns pointing at the site and post a holding note on your Google Business Profile giving a phone or WhatsApp number for orders. Then act on the layer you identified. Revert the last change if there was one. Restore from a verified backup if there was not. Raise a support ticket with the exact error text and timestamps rather than the words site is down.

How to judge your own response

The metric that matters is time to detection followed by time to restore. If a customer told you then detection failed and monitoring is the cheapest fix available. The other serious question is whether you can name the cause afterwards. An outage with no identified cause will recur.

The metric that flatters is the site working again. Clearing a cache or restarting a service often restores the site without touching the cause. That is a reprieve rather than a resolution and it tends to expire at a worse moment.

The mistake that costs the most

The common mistake is changing name server or DNS records during an incident in the hope of moving the site somewhere healthier. Those changes take time to spread across the internet and that time is outside your control. You convert a short outage you could have fixed into a long one you can only wait out. Worse, you lose the ability to tell whether the original fault was ever repaired. Take a copy of the broken state before you change anything, because files and databases get deleted in frustration and that copy is the only evidence you will have.

If customer data may be involved

Indian rules work on two fronts here. Directions issued by CERT-In require certain categories of cyber incident to be reported to it within a short prescribed window. Separately the Digital Personal Data Protection Act 2023 creates a duty to notify a personal data breach to the Data Protection Board and to affected individuals. Whether an incident falls inside either mechanism depends on what happened and what data was exposed. A qualified professional should confirm what applies to your situation.

This guide explains how something works. It is not legal, tax or financial advice, and rules change. Confirm anything regulatory with a qualified professional before you act on it.