Why Websites Go Down and How to Find Out First

Websites go down for mundane reasons: an SSL certificate expires, a hosting or domain bill goes unpaid, a server update breaks compatibility, not every service comes back after a reboot, or the site hits a third-party limit. There is one way to find out before your clients do: automated monitoring that checks the site more often than visitors open it.

What makes websites go down most often?

In our practice most outages are not hackers or data-center fires. Attacks do happen, but for a small business the reality is usually more prosaic: five everyday scenarios.

An expired SSL certificate looks like this: one morning, instead of the site, the browser shows visitors a red “Your connection is not private” page. Most people close the tab right away. The site is technically alive, ads keep running, clicks keep coming, and there are zero leads. The certificate renews automatically for years, until one day the automation fails, and then everything depends on whether somebody notices before the visitors do. The owner usually learns about it last, when some acquaintance works up the nerve to ask why the site is “broken.”

An unpaid hosting or domain bill is the second classic. The reminder email drowned in the inbox, the card on file failed, and the host switched the site off. In the best case everything returns after payment. In the worst case the data is already deleted and there is nothing to restore from. Domains have their own twist: an expired domain eventually goes back on the open market.

Server system updates are entirely out of the owner’s hands. The host updates its software, and part of the site stops working because of an incompatibility: errors appear on some pages even though nobody has touched the site in months.

A server reboot, planned or not, does not always pass cleanly either. The server comes back but a particular service does not, say the database, because it was never added to autostart. From outside it looks sneaky: the homepage opens fine while the form is silent. A breakage like this can live for weeks, because until somebody tries to submit the form, nobody notices anything.

The fifth cause is third-party limits. A site leans on outside services like a payment system or maps. Each has limits, and while traffic is low you never see them. On a peak day the service stops responding and takes part of the site down with it, precisely when you have the most visitors.

The most expensive “working” site

Colleagues passed this story on to us, and to be clear up front: the developer in it was not ours. A blogger filmed a reel linking to her landing page, which sold access to a private Telegram channel. The video went viral, millions of views, and 50,000 visitors landed on the site. Payments: zero. Not the first visitor and not the hundredth could pay, because the developer had forgotten to switch the payment system from test mode to live. The site loaded fast, the checkout page looked fine, and an availability monitor would have shown green the whole time. By every technical measure the site “worked”; it just quietly refused money on the best day of its existence. Traffic like that does not come back on demand, and a second viral video may never happen. This is why checking “does the site open” is only half the job; the other half is checking the critical path that brings in money or leads. In our monitoring the lead form gets its own check, once a day, for exactly this reason.

What did our monitoring catch last month?

We currently watch 20+ sites. Over the last month monitoring caught 3 incidents, and all three were on our own experimental sites, where we try out new setups; client sites went through the month quietly.

A typical example: load grew on one of the experimental sites and page speed dropped. The alert arrived in Telegram, we added server capacity, and that was the whole incident. Nothing heroic, which is the point: a problem you learn about early stays small. Had the same spike hit a client site, the scenario would have been identical, and the owner would have learned about the incident from our message rather than from downtime.

And here is a case no monitoring would catch. A client published a phone number with a typo on his site. Technically everything worked: pages opened, the form sent leads. There were just no calls. Attentiveness found the mistake, not automation. The lesson we kept from it: “the site works” and “the site earns” are two different checks, and only the first one can be fully automated.

How do you find out about downtime before your clients?

The mechanics of our monitoring are simple. Site availability is checked every hour. The SSL certificate, the domain expiry and the lead form are checked once a day. When a check fails, an alert goes straight to our Telegram. Monitoring runs around the clock; we respond during working hours, Mon–Fri 09:00–19:00 Kyiv time, with an average reply taking about 30 minutes.

If you have no automated monitoring, the minimal manual alternative is this: once a week, open the site in an incognito window on your phone, send yourself a test lead through the form, and check the calendar for when the domain and hosting payments come due. It is far worse than an hourly check, but incomparably better than hearing about downtime from clients.

For sites on a pageever subscription, monitoring is already included even in the Basic plan at €10/mo or €96/yr. If your site lives on its own hosting and is not moving anywhere, there is a separate service: monitoring for external sites at €50/yr. Nothing gets migrated; we simply put the site under watch.

Last month all 3 incidents reached us as Telegram alerts, not as phone calls from clients.