What keeps running
What has to keep running, be renewed and be paid for once a website is live, what breaks when one piece stops, and how to find which piece it was.
Rented, piece by piece
A small hotel near Annecy had its booking site built by a freelancer two years ago. One spring morning, the site vanished. Nobody had hacked it: the reminder to renew the domain name had gone to the freelancer's old email address, and the card on file had expired.
A website is never bought once and for all. It's a set of rented pieces, each with its own renewal. The domain name is usually rented by the year from a registrar (a company that sells domain names, such as OVH). Hosting, the computers that answer visitors, is paid monthly or yearly, and so is a database or back-end service such as Supabase. The certificate behind the padlock lasts a few months and is normally renewed automatically. Outside services each have their own subscription or free plan: payments, email sending, maps, AI. And the software itself needs updates, especially a WordPress site and its plugins, which attackers scan for known weaknesses.
Each piece has a renewal date, a bill, and an account that someone has to own.
When one piece stops
Each piece fails in its own way, so the symptom points to the piece.
If the domain lapses, the address stops leading anywhere and the browser says the site can't be reached. Worse, after a grace period someone else can buy the name. A wrong DNS setting, or a host that's down, gives the same message. If the certificate expires or doesn't match the address, the site is still there, but the browser can't prove it's genuine, so it shows a full-page warning that the connection is not private.
If the page loads but search, login or payment fails, then the name, the certificate and the hosting are fine. What's broken is behind the page: the back end, the database, or an outside service that is down, unpaid or past the limit of its free plan.
That last kind can stay hidden for weeks. A contact form whose email service has stopped sending looks perfectly normal, while the messages quietly go nowhere.
First question: everyone, or just me?
Check from another network before you wake anyone up.
On a Saturday morning, the marketing manager sends you a screenshot: "The site is down!!" Before calling anyone, find out whether it's down for everyone. Open it on your phone over mobile data, or use an "is it down" website. Plenty of alarms turn out to be a hotel's Wi-Fi, a company firewall or one person's browser.
If it's down for everyone, read the symptom and go to whoever owns that piece. For a name that leads nowhere, check the registrar's account and its renewal emails, then the hosting provider's status page. For a certificate warning, contact whoever manages the hosting. For a feature that fails, look at the outside services' status pages, and ask the developers to read their logs, the record the server keeps of what it did.
Don't jump to "we've been hacked". Expired, unpaid and misconfigured are far more common. And when a site worked yesterday, something changed or ran out overnight: a new version went live, a renewal failed, a quota or a bill came due.
Before the builders leave
Ownership gets lost at handover: when an agency's contract ends, a freelancer moves on, or the intern who set everything up leaves. That's the moment to collect it all.
Ask for a complete list of the services the site depends on, with what each one costs and when it renews. Then ask for the accounts themselves. Each one should be in the company's name, paid with a company card and reachable by more than one person, so renewal and alert emails land in a shared mailbox rather than with someone who left two years ago. Switch on automatic renewal for the domain.
Ask who keeps backups of the data, and whether anyone has ever restored one, since an untested backup may fail on the day you need it. Decide who installs security updates. Set up uptime monitoring, a small service that checks the site every few minutes and alerts you before customers notice. Platforms that bundle everything, like Shopify or Webflow, make the bill simpler but are hard to leave, so ask what you could take with you.
What to ask
Send these questions before launch, and again at every handover.
Ask for a written list of every service the site relies on: the domain, hosting, database, email sending, payments, maps, AI, and any paid plugins or apps. For each one, you want the cost, the renewal date and the account that pays. Ask whose name each account is in and which card pays for it, and move anything on a personal card or an agency's account over to the company. Ask which services are on a free plan, what its limits are, and what happens when you go past them: some free services pause a project that sits unused.
Ask where the backups are, how often they run, and when one was last restored. Ask who installs security updates, how often, and at what cost. And ask who gets the alert when the site goes down, and whether that person still works here.
Practise this strand
The questions on The map put you in the situations this lesson describes. You answer in your own words, and you get a level, feedback and a full answer.