Your website is live. What to do every month so it doesn't die

Friday, 9 p.m. A Telegram message: "The site won't open, the browser says the connection isn't secure." I open it and check the certificate. Expired today at 18:00.

This wasn't our client, or rather, not yet. Another contractor had built the site, the certificate was renewed by hand, and the person who used to do it had long since left. We reissued the certificate in ten minutes and set up automatic renewal. But for three hours on a Friday evening, a site with ads running was showing visitors a red warning.

I hear stories like this all the time. Below is what we do so our clients don't have them.

Why websites "die"

There's almost never one big disaster. Small things pile up:

• the certificate didn't renew;
• the domain wasn't paid because the reminder went to the inbox of someone who'd left the company;
• the server disk filled up with logs and the database stopped writing;
• a library hadn't been updated for two years and a vulnerability turned up in it;
• the enquiry form broke after an edit, and for a month nobody noticed there were no enquiries.

That last one is the nastiest. The site looks alive. It opens, it looks nice. It just stopped bringing in clients. And the owner concludes that "the website doesn't work as a channel", when really one integration broke.

What we do every month

We have a routine. It's boring, and that's the point.

This takes two to six hours a month per site, depending on size. Much of it can be automated, but someone still needs to look with their own eyes.

The test enquiry comes first

It sounds silly, but it's item number one. We send the enquiry by hand, like a normal visitor. We don't read the code or the logs; we fill in the form and wait for the message. If the message doesn't arrive, everything else on the list can wait.

Backups nobody ever tested

A backup you've never restored from is a hope, not a backup. I've seen 0-byte archives being "successfully" created by cron for months, because the user didn't have read permission on the database.

Our minimal setup for Django + PostgreSQL in Docker looks roughly like this:

# every night at 03:00: dump the database, compress, keep 14 days
0 3 * * * docker compose exec -T postgres pg_dump -U app app \
  | gzip > /backups/db-$(date +\%F).sql.gz \
  && find /backups -name "db-*.sql.gz" -mtime +14 -delete

On top of that, media files (images uploaded through the admin) are synced separately, and a copy of everything lives on a different server. If the backup sits on the same disk as the site, it dies with the site.

What it looks like on long-running projects

Our two longest maintenance contracts are the website of the law firm Legal Alliance and the media portal of the TV channel MY5.

Legal Alliance runs Django with DRF and Celery on the backend and Nuxt 3 on the frontend. Besides the core pages there are news, video, search and a company history, all regularly updated by the lawyers. Most of the support work isn't bugs but small tasks: a new practice section, a form tweak, team updates. Plus the boring items from the list above.

MY5 is one of the biggest family TV channels in the country. TV schedule, series, shows, a blog, vacancies. Load matters here: the channel's audience is large, traffic comes in waves after broadcasts and promos, and the server has to ride those waves.

Our yearly maintenance cycle looks roughly like this:

Monitoring: know before the client does

The worst thing that can happen to a contractor on support is hearing about an outage from the client. It means we were asleep.

Basic monitoring is almost free. An external service opens the home page every minute or two and posts to our team Telegram chat if it doesn't respond or responds with an error. On the backend we send Django errors to a separate channel, so we can see when something starts throwing 500s.

Then there are the "silent" problems. The site may load while:

• the Celery worker has died, and emails or notifications aren't going out;
• the task queue keeps growing;
• the API responds, but returns empty lists because a filter broke.

For these we add simple checks: a health endpoint that asks not just "is it alive" but "is it working". It's a few dozen lines of code, and it has saved us more than one unpleasant conversation.

Content and analytics are maintenance too

A technically healthy site that hasn't been updated for a year also dies, just more slowly. A visitor sees news from two years ago and closes the tab. Google sees nothing changing and shows the site less.

We don't write content for clients, but once a month we look at analytics together with them. Not a twenty-page report, just three questions: how many people came, how many left an enquiry, which page got worse. Sometimes that's enough to notice that the section everyone considered the main one is never opened.

If you want to run a basic check yourself, we have a technical SEO audit checklist; many of its items overlap with monthly maintenance.

Can you maintain a site yourself

Yes, if someone on your team understands servers. Even if you hand everything else to a contractor, I'd keep three things in-house:

1. The domain and hosting are registered to the company, and you hold the logins.
2. Renewal reminders go to a shared address or chat, not an employee's personal inbox.
3. Once a month, someone on your team sends a test enquiry themselves.

If there's no such person, contractor support costs less than one rescue after everything has broken. In my experience, fixing a "dead" site with no proper backups, where nobody remembers how it was built, costs about as much as several years of calm maintenance.

My personal takeaway after these years is simple: good maintenance is invisible. If a client only remembers us when they want to add something, we're doing it right.