Why Your Website “Goes Down” at Night — and How to Be the First to Know

Your website went down at 2 a.m., and you found out at 9 a.m. — from a customer’s message. Seven hours of downtime that didn’t have to happen.

Why at night

Heavy jobs run at night: backups, updates, report recalculations, log cleanup. They eat up memory and disk, and nobody is around. On top of that, night is when most automated attacks and password brute-forcing happen — the time when nobody is watching the server.

Five typical causes

1. The disk filled up. Logs and backups grew for months, and the nightly backup used up the last gigabytes — the database stopped writing, and the site returns an error.
2. Memory ran out. A nightly process (indexing, a report, an update) took all the memory, and the system “killed” the web server or the database.
3. The SSL certificate expired. Right at midnight. Browsers show a warning, and customers leave.
4. An update that broke something. An automatic OS update restarted the server, and the service didn’t come back up after the reboot.
5. An attack. RDP or SSH password brute-forcing that loaded the server so heavily it stopped responding.

Why people find out in the morning

Because nobody watches the server at night — and nobody should have to. Software should do the watching: check the site every minute, keep an eye on disk, memory and services, and wake someone up only when something has actually broken.

What monitoring should do

• Check site availability and response time from multiple locations.
• Warn about disks filling up in advance — at 80 %, not 100 %.
• Track memory, CPU and key processes: the web server, the database, 1C.
• Remind you about expiring certificates and domains two weeks ahead.
• Send alerts to Telegram — where they’ll definitely be seen.

An alert is only half the job

Finding out at 3 a.m. that the site is down is already better than at 9 a.m. But someone has to get up and fix it. On the plan with priority incident response, our engineer gets the alert too: they restart the failed service, free up disk space and then write up what happened and how to prevent it from happening again.

How much it costs

Website monitoring is 1 000 UZS per day, server monitoring 2 000, and with priority engineer response to incidents — 5 000 UZS per day. For comparison: a night of downtime for an online store costs orders, and 1C being unavailable in the morning costs an hour of work for the entire accounting team.