uptime and backups

Uptime is a simple idea: what fraction of the time can a visitor actually reach your site? A site that is down for a day a month is at about ninety-seven percent. That sounds fine until you realise it is a day of lost calls. Backups are the other half of the same worry: if something goes wrong, can the site be put back the way it was?

On a traditional rented server, both of these are real, ongoing jobs. The server needs monitoring. Plugins need updating, and updates sometimes break things. Backups need a plugin or a service, need to be tested, and need somewhere to live. Most small business sites I inherit have never had a backup restored, which means nobody knows if the backups work.

On the sites I build, both problems mostly go away, not because I am clever about them but because the way the site is built removes the causes.

Why it matters to you

You do not think about your site until it is gone. The moment it is gone, it is the only thing you think about. A site that quietly stays up is worth more than one with impressive features that goes dark twice a year.

Backups matter most on the day a change goes wrong. Somebody edits the wrong thing, a plugin update breaks a page, a provider makes a mistake. On a WordPress site, recovering from that can mean restoring last night’s copy and losing a day of changes, or worse, discovering the backup is broken. I would rather you never have that day.

How I set it up

Uptime comes from where the site lives. A static site on Cloudflare’s network is a set of files copied to hundreds of data centres. There is no server to crash, no database to lock up, and no plugin update to go wrong at two in the morning. If one data centre has trouble, the next nearest one serves the site instead. Keeping it running is a job that is mostly already done by the architecture.

Backups come from version control. The entire site, every page and every line of code, lives in a GitHub repository that records every change ever made, who made it and when. Rolling back a mistake means picking the version before it and deploying again. That takes minutes. It is also how the site was built in the first place, so it is never out of date and never untested.

When I replace an old site, I keep the old one frozen as a backup for thirty days after the switch. If anything was missed, it is still there to check against. After that, it is cancelled and nothing points at it any more.

What it looks like in practice

Mostly, it looks like nothing happening. The site stays up. Changes go live and stay live. If I ever make a change you do not like, I put it back to how it was, and you do not lose anything else in the process.

In the arrangement, it is one line on my side: updates, fixes, uptime and backups. It sits there so that it is clearly my job and not yours. Your side of the same line reads “tells me when something looks wrong”, and on a site built this way, that does not come up often.