Friday afternoon. The phone rings, the customer sounds patient and slightly apologetic, and they say: "your website is down". You open the site on your own computer. It comes up exactly as usual, images in place, menu working.
That is normally where it goes wrong. You say it works at your end, the customer says it does not work at theirs, and half an hour goes on arguing about a fact neither of you has checked. What follows is what you actually do in those ten minutes, in order.
Is the site really down?
Before you ring anybody, do three things.
- Look from another network. Take your phone, turn the wifi off and open the site on mobile data. Now you are outside your office and outside your own internet connection.
- Look from another browser. Or the same browser in a private window. That rules out everything already stored on your machine.
- Get somebody else to try. Anybody, as long as they are not in the same building and not on the same network.
If the site opens on your phone over mobile data, the problem is not your site. One person's browser is holding an old copy, one office network has a fault, one company firewall is blocking something, or a computer still remembers yesterday's address: if the site or the email has recently moved to a different host, the new address does not reach every computer at the same moment. You simply did not know that until you looked from somewhere else.
Two minutes of checking saves a whole chain of people hunting for a fault that is not there. If the site fails to open in all three, then it really is down.
Read what the screen says
An error message looks like technical noise, but it says one thing very clearly: whose problem this is. Photograph the screen first, because these messages disappear.
- "Cannot connect" or "server not found". The machine is not answering, or the address no longer points anywhere. Ring the host.
- 404. One page is missing, not the whole site. The server is running and answering you properly. Ring your web company, though not on a Friday evening. If the 404 comes up on the front page and on every address, what is missing is not one page but the map of them: same door, but the Friday-evening rule holds for a single page only.
- 500. The server received the request and the site's own code tripped over itself. Usually something broke during an update, often a plugin. Ring your web company.
- 503. The server is alive but cannot keep up, or is in maintenance mode. If you did not order maintenance, ring the host.
- A database error. The site is there, but its content cannot be reached. The line runs between host and web company here: ring whichever answers faster and let them bring the other in.
- A security warning filling the screen. Read the line under the heading. If it mentions a certificate or a date, the lock has expired and the site itself is fine: ring the host. If it says "dangerous site" or "deceptive site", the browser is warning you about the content rather than the lock: ring your web company. What that warning means and how to get rid of it is a story of its own.
- A registrar parking page, a for-sale sign, or a notice that the domain has expired. Ring the registrar, and do it now.
- Content in a language you do not use, advertising you never ordered, or a redirect somewhere else. The site has most likely been broken into. Ring your web company and the host straight away, and fix nothing yourself until somebody knows how they got in. What a site that has been broken into actually looks like is written out elsewhere, along with the longer version of the certificate and backup arguments.
An expired domain is the quietest of the lot: it gives you no warning on screen, it simply stops being valid, and your email stops with it. The reminder went to an address nobody reads any more, or to somebody who left two years ago. You can check the expiry date today in your registrar's control panel, or for an .ee name in the registry's public whois lookup. Whose name the domain is in is a story of its own.
Three doors
Most outages drag on not because the repair is hard, but because nobody knows which door to knock on. There are three doors, with different opening hours and entirely different responsibilities.
- The host looks after the machine your site sits on. They are responsible for the machine answering, the certificate renewing and there being room on the disk. A large host has support around the clock, a smaller one on working days.
- Your web company is responsible for the site's own content and code. They fix a broken page, a broken form, and the update that took something down. Most of them are not on call on a Friday evening unless you have agreed that separately.
- The registrar holds your domain. You go to them when the domain expires or the address itself disappears. They are the easiest of the three to overlook, because in a normal year you never speak to them at all.
Often two of these are the same firm, sometimes all three. That is convenient, but only if you know it is the case. Otherwise you are the person ringing the web company about a certificate and the host about some wording, and getting a polite answer from both saying it is not theirs. The words themselves are simpler than they sound.
The crisis card
Everything above assumes you know who to ring. You cannot work that out during an outage, because that is precisely when accounts, invoices and old emails are hardest to find.
Write one sheet of A4, or one file. It does not have to be pretty, it has to exist and live somewhere you can reach when both the website and the work email are down.
- The registrar's name, who owns the account, and the expiry date.
- The host's name, the control panel address and the contract number.
- Who has access. By name, not "we have it somewhere".
- Where the backup is, how old it is, and whether anybody has ever put one back.
- Your web company's name and a phone number. A number, not a general info address.
- Which number answers outside working hours, if such a number exists at all.
Let us say this plainly, against our own interest: you can write that list yourself and you should not pay anybody for it. It is not a service, it is half an hour of work and one file. If somebody offers it to you as a package, they are selling you your own details back.
If there is a line you cannot fill in, that line is the problem, and it is usually the one that gets expensive on the next bad day.
What an SLA actually promises you
If your hosting contract carries an uptime promise, it is worth knowing what it covers: usually, if the provider falls short, you get part of your monthly fee back. Not lost orders, not a customer's patience, not the morning you spent on the phone.
The figures themselves are smaller than they sound. 99.9% uptime means the site may be down for roughly eight hours and forty-five minutes a year. 99% sounds almost as good, but means over three days of downtime a year, and the provider is still keeping its promise.
None of that is a reason to change contracts. It is a reason to know what you bought. What is in hosting is almost always the same, and support separates providers more than a percentage does.
What you do while the site is down
Your website is not the only place a customer finds you. The phone works. Your Google business listing works, and you can change the opening hours and post a notice there. Social media works. If your email runs on the same domain and is down as well, tell somebody who can pass that on straight away: a silent inbox is worse than a broken site.
One sentence is enough. "Our website is down at the moment, we are working on it, please call this number in the meantime." Somebody who reads that will wait. Somebody who sees nothing assumes you have closed.
Most outages are short and unimportant. A server drops out for a minute, an update falls over and is fixed before anybody notices, the host reconfigures something overnight. Without monitoring, those never reach you at all, and most of the time they do not need to. A change made in a hurry, an old copy restored at the wrong moment, or a web company swapped in irritation all cost more than the outage they were meant to solve.
Afterwards: two questions
Once the site is back, the temptation is to forget about it. Make one more call and ask two things: what happened, and what is different now.
"It sorted itself out" is not an answer. Did somebody restart the machine, did the load drop, was an update rolled back, did the certificate finally renew? Every one of those is a perfectly normal answer. No answer at all means it will happen again, and you will know exactly as much then as you do now.
The second question matters more. If the answer is "we will keep a closer eye on it", nothing changed. If updates now run on a copy before they touch the live site, if the page is watched by monitoring (a machine that tries to open it every few minutes and sends word when it does not) and that tells you before the customer does, or if somebody gets told when a certificate fails to renew, then something changed. That difference is also what a monthly upkeep fee is for.
An outage tests your phone book
The outage itself is not a disaster. Servers go down, certificates expire, updates break, and all of it happens to the most careful people there are.
An outage does not test your website, it tests your phone book. And you can run that test this afternoon with nothing down at all: take a sheet of paper and try to fill in those six lines without asking anybody. The number of lines you stall on is your answer. If it is more than two, go and ask your host and your registrar for those lines before Friday comes. If nobody answers, ask us.
Frequently asked questions
Before you ring anybody, run three checks that together take two minutes. Open the site on your phone with the wifi turned off and mobile data on. Open it in another browser, or in a private window of the same one. Get somebody who is not in your building and not on your network to try it. If it opens on mobile data, the problem is not your site: one person's browser is holding an old copy, an office network has a fault, a firewall is blocking something, or a computer still remembers yesterday's address. If the site fails all three, it really is down, and the next step is to read the error message on screen.
The error message usually decides it. "Cannot connect" and a 503 go to the host, who looks after the machine your site sits on. A 404 or a 500 goes to your web company, who is responsible for the site's content and code. A full-screen security warning depends on the line under the heading: one that mentions a certificate or a date belongs to the host, one that says "dangerous site" or "deceptive site" belongs to your web company. A registrar parking page, a for-sale sign or a notice that the domain expired go to the registrar, but content in a language you do not use, advertising you never ordered or a redirect elsewhere usually means the site has been broken into: ring your web company and the host at once. A database error sits on the line between the two: ring whichever answers faster.
Usually it promises that if the provider falls short of the agreed uptime, you get part of your monthly fee back. It does not cover lost orders, a customer's patience or the morning you spent on the phone. The figures are smaller than they sound: 99.9% means the site may be down for roughly eight hours and forty-five minutes a year, and 99% means over three days of downtime a year without the promise being broken at all. That is not a reason to change contracts, only a reason to know what you bought. Support separates hosts more than a percentage does.
One sheet of A4, or one file, written before the outage and kept somewhere you can reach when both the website and the work email are down. It holds the registrar, who owns that account and when the domain expires, the host's name and control panel address, a list by name of who has access, where the backup is and how old it is together with whether anybody has ever put one back, and your web company's name with a phone number. Add the number that answers outside working hours, if one exists. You write that list yourself and should not pay anybody for it: it is half an hour of work and one file.
Read next
There is a News item in the menu with three posts under it, the newest dated three years ago. A visitor reads the date before the headline, and the date asks a question the page never answers: is this company still there? This is not a Google penalty, it is a signal to a person. Three honest options for a dead news page, and a list of the dates that make promises on your site.