There is a particular silence that happens in a meeting when someone asks, "who looks after the website?" Everyone glances around. Marketing says IT. IT says it was an agency. The agency was three years and two contracts ago. The site is up, so the question dissolves and the meeting moves on — until the morning it isn't up, and the same room has the same conversation under pressure.
This is not a technical problem. Monitoring is cheap and easy to set up. The gap is a management one: nobody has decided, in advance and in writing, who acts when the alert fires and what they are permitted to do. That decision takes about an hour to make. Here is how to make it.
The failure mode is orphaned ownership, not missing tools
Websites end up unowned in a predictable way. Someone builds or commissions it. That person leaves, changes role, or the agency contract ends. The site keeps working, so nothing forces a handover. Ownership does not get transferred — it evaporates, and what remains is a shared assumption that "someone" has it.
You can detect this in your own team in one question, asked without warning: if the website were down right now, what is the first thing you would do? If the answers differ, or if any of them is "ask around," it is unowned. This is the same gap that opens whenever a role changes hands without a deliberate transfer — the pattern is worth reading in full in our guide to handing over when someone leaves your team.
Step 1: write the ownership record
One page. It exists so a competent person who was not involved in building the site can act at 8am without hunting. Put it where your team already keeps documents, not in one person's inbox.
- Domain registrar — where the domain is registered, whose account, and the renewal date. Domains expire, and an expired domain looks exactly like a hosting failure to everyone except the person who checks.
- DNS — where the records are actually managed, which is often not the registrar.
- Hosting — provider, plan, and how to reach their support, including what account details they will ask for before they help.
- The site itself — the admin URL, who holds administrator accounts, and how access is granted (not the passwords; those belong in a password manager).
- Anything the site depends on — payment gateway, email/SMTP sending service, booking system, CRM integration.
- The current maintenance arrangement — in-house, retainer, or nothing. If nothing, say "nothing" explicitly; an honest blank is more useful than an implied arrangement.
- Named responder and backup — a person, not a department.
Most teams cannot fill this in from memory, and the gaps are the deliverable. Finding out that nobody knows who controls DNS is worth the hour on its own.
Step 2: decide what counts as an incident
Alerts that mean everything mean nothing. Before you tune any tool, agree three tiers in plain language:
- Down — the public site does not load for customers. Somebody acts now, including out of hours if that is the business you are in.
- Degraded — the site loads but something important doesn't work: checkout fails, the contact form doesn't send, the login page errors. Acts today, in working hours.
- Noise — a single failed check that recovers on its own, a certificate expiry warning weeks out, a slow response overnight. Goes on a list, gets reviewed weekly.
The value here is not the taxonomy. It is that you have decided in advance what justifies interrupting someone's evening, so the person on the receiving end does not have to make that call while looking at a red notification.
Step 3: make the alert reach a human
Monitoring that emails a shared inbox is not monitoring; it is archiving. Three requirements:
- Alerts go to a named person's phone, with a named backup for holidays and illness. A rota of two is enough for most small teams.
- The alert states what to do first. Even one line — "check status page, then contact host support with account ref X" — removes the paralysis that makes the first ten minutes of an outage disappear.
- You test it. Trigger the alert deliberately, at a time you choose, and watch it arrive. Untested alerting fails silently and you discover it during the outage. Re-test after any change of phone, provider, or staff.
Check from outside your own network, and check more than the homepage — a site can return a page while its checkout is broken. If revenue depends on a specific flow, monitor that flow.
Step 4: decide the authority in advance
The most expensive minutes in an outage are the ones spent asking for permission. Write down, before anything happens:
- What the responder may do without asking: restart, restore from backup, put up a maintenance page, open a ticket with the host, call the maintenance provider.
- What requires a decision-maker: anything that costs money above a threshold, anything touching customer data, anything that changes the site permanently.
- Who tells customers, through which channel, and roughly what they say.
Delegation without authority is just blame in advance. If you name a responder, give them the account access and the mandate to use it.
Step 5: choose in-house or contracted, and say which
There are two honest answers, and both work: someone in-house owns it with the time and access to act, or a maintenance provider owns it under an agreement. What fails is the third state — assuming a provider is watching when the relationship ended, or assuming a colleague is watching when it has never been in their objectives.
If you contract it, be specific about what you are buying: monitoring, updates, backups, and a defined response route. A provider like WPCare, which runs WordPress maintenance, server management, and emergency support for businesses in Malaysia, is an example of that shape — the point for a manager is not the vendor but the contract, which should name who to contact, through which channel, and what falls inside the plan versus what is billed separately. Read that before you need it, not during.
And if you keep it in-house, treat it as real work: put it in someone's objectives, give them time for it, and review it. Unfunded responsibility is how sites become orphaned in the first place.
Step 6: fifteen minutes a month
Put a recurring item on one agenda you already run. Confirm the alert path still works, review the noise list, check that anyone who left has had their access removed, and confirm nothing is approaching expiry — domain, certificate, licences. It takes minutes when it is routine, and it is the mechanism that stops ownership evaporating again the next time someone changes role.
FAQ
We're a small team with no technical staff. Is this overkill?
The opposite — the smaller the team, the more the site depends on a single person's memory, and the faster ownership disappears when that person moves on. The whole record is one page and the review is fifteen minutes a month. Scale the response plan down if you like; do not scale the ownership record down, because it is what lets an outsider help you quickly.
Should someone be on call at night for a website?
Only if being down overnight actually costs you something. For a business-hours brochure site, "we act at 9am" is a perfectly good, explicitly agreed answer. What is not acceptable is leaving it undecided, so the alert lands on someone at 2am who does not know whether they are supposed to care.
What if we already pay someone and I'm not sure what they cover?
Ask for the scope in writing, then compare it against your ownership record and look for the gaps: monitoring, backups, updates, response route, out-of-hours. This is a fair, routine question, and a reasonable provider will answer it plainly. Discovering a gap now costs an email; discovering it during an outage costs considerably more.
Who should hold the domain registration?
The business, in a company-controlled account — not an employee's personal account and not the agency's. This is the single most common ownership trap, because a domain in someone else's account is difficult to recover exactly when you most need it. If yours is in the wrong place, transferring it is a scheduled task, not an emergency.
Next step
Ask your team the question at the top of this article — if the site were down right now, what would you do first? — and write down whatever comes back. Then fill in the one-page ownership record, name a responder and a backup, and test the alert once. If the honest conclusion is that nobody in-house can own it, contract it deliberately: a provider such as WPCare covers monitoring, maintenance, and emergency response for WordPress sites, and the thing to agree up front is the response route and the scope, so that the next alert has a name attached to it instead of a silence.
