Every website goes down at some point. The difference between a fifteen-minute scare and three days of damage is not in having avoided the failure, it is in what was prepared before it. This article is about that preparation.
The 5 most common causes of downtime
- Expired domain. The most frequent cause and the most avoidable. The card on file expired, the warning email went to spam, and the whole site disappears, along with the domain email. Keep auto-renewal on, the registrar contact current, and your own calendar reminder.
- Expired SSL certificate. The site is still on the server, but the browser shows a red insecure connection warning, which in practice is the same as being down. It usually happens when automatic renewal stops working and nobody notices.
- Human error during an update. An updated plugin, a swapped theme, an incomplete deploy, a setting saved wrong. This is the most common cause among sites that are actually being maintained.
- Hosting failure. Provider outage, resource limits exceeded, full disk, database down. Here control is out of your hands, and what remains is knowing what your plan promises and where to go if the promise is not kept. That subject is in shared hosting, VPS or cloud.
- Compromise or malware. Outdated software, a weak password, an abandoned plugin. Beyond the downtime, there is the risk of the domain being flagged as dangerous by browsers, which takes weeks to reverse.
Notice that three of the five causes have nothing to do with code. They are administrative. That is why continuity is a matter of process, not only technology.
Before any technical diagnosis, confirm the problem is yours. Ask someone on another network to open the site, or use a service that tests the address from several countries. A local DNS cache, a corporate network with filtering, and even a browser extension can perfectly simulate a site being down while it works fine for everyone else.
The 3-2-1 rule applied to websites
The 3-2-1 rule is an old backup standard and it still holds:
- 3 copies of the data, counting the one in production.
- 2 different media or services, so one failure does not take everything.
- 1 copy off-site, with another provider or in another region.
Translated to a website: production counts as one copy; the hosting provider automatic backup is the second; and a copy downloaded and stored elsewhere, on a different cloud service or an external drive, is the third. The last point is the critical one. A backup kept only inside the same panel at the same provider is not an off-site backup: if the account is suspended or compromised, you lose both at once.
What needs backing up besides the files
Almost everyone remembers the site files and forgets the rest. The full list:
| Item | Why it matters |
|---|---|
| Site files | Code, images, uploads and server configuration |
| Database | Content, articles, users and orders. Without it, the files do not assemble a site |
| Mailboxes | If email is on the same domain, the client conversations live there |
| DNS zone | Every record. Rebuilding from memory is slow and error-prone |
| Certificates and credentials | Registrar, control panel, repository and API access |
| Environment variables | Keys and settings that never live in the repository and nobody remembers later |
It is worth exporting the DNS zone to a text file and storing it with the backup. It is small, rarely changes, and saves hours during an emergency migration. On who owns those accesses, there is a whole article in who owns your website, and it is worth reading before the emergency happens.
Pay particular attention to the TTL on your DNS records. That number defines how long providers keep an answer before asking again. With a 24-hour TTL, a server change can take a full day to apply for everyone. If you already know a migration is coming, lower the TTL to a few minutes in advance and raise it again once things settle.
Backup frequency by site type
The right question is not how often to back up, it is how much content you accept losing. If the backup is daily, the worst case is losing one day of work.
| Site type | Files | Database |
|---|---|---|
| Static company site | On every change | Not applicable |
| Site with an active blog | Weekly | Daily |
| Site with forms and leads | Weekly | Daily |
| Online store | Daily | Continuous or several times a day |
Define how long each copy is kept too. Keeping only yesterday backup is risky: if a problem started two weeks ago and nobody noticed, every recent backup is already contaminated. A common retention scheme keeps the last seven daily, four weekly and three monthly copies.
An untested backup is not a backup
This is the part almost nobody does, and the one that separates a real plan from a false sense of safety. A backup file that has never been restored is just a large file. It may be truncated, it may be missing the database, it may have been generated with an error nobody read in the log.
The restore test is simple:
- Download the most recent backup and check that it opens and has a plausible size.
- Create a separate environment: a test subdomain, a local server or a temporary install.
- Restore files and database there, never over production.
- Open the home page, an inner page, an image, and log in. Confirm the content is current up to the expected date.
- Write down how long the whole process took. That number is your real recovery time estimate.
- Delete the test environment, making sure it is not indexed while it exists.
Do this at least twice a year. It is the only way to know the safety net is really there.
Free uptime monitoring
Finding out the site is down because a client called is the worst possible scenario. Monitoring services make a periodic request to your site and alert you by email, message or app when it stops responding. Free options check every few minutes, which is enough for most businesses.
Three settings worth using: monitor an inner page as well as the home, because the home may be cached and answer even when the rest is broken; monitor SSL certificate expiry, which many services offer alongside; and send alerts to more than one person, in case whoever receives them is on holiday.
A one-page response plan
When the site goes down, nobody is in the right frame of mind to improvise. Write it down, in a document reachable outside the site itself:
- Who takes the lead. Name and phone of the person in charge and a backup person.
- Where the accesses are. Domain registrar, hosting panel, DNS, repository. In a password manager with shared access.
- Where the backups are. The exact location and how to download them.
- Diagnosis in three steps. Is the domain active? Does DNS answer? Does the server answer? Each answer points to a different responsible party.
- Hosting support contact. Channel, service hours and contract number.
- Communication. What to say on social media and to clients who ask, so nobody improvises.
One page. Printed or saved somewhere that does not depend on the site that just went down. Review that page alongside your maintenance routine, because contacts and accesses change.
If you do not know where your backups are or when they were last tested, talk to ALB Seven. This is the kind of conversation that is far better to have before the problem.