Why Your Website Keeps Going Down at Night

Recurring downtime at the same time each night is almost always a scheduled process. Unlike random outages caused by traffic spikes or hardware failures, consistent nightly downtime has a clock attached to it — which makes it diagnosable if you know where to look.

Step 1: Find Exactly When It Happens

Before you can find the cause, you need precise timing. If you don't have an uptime monitor with timestamps, set one up before anything else — you can't diagnose nightly downtime if you're only discovering it the next morning with no data.

With monitoring data, identify:

• What time does downtime start? (to the minute)
• How long does it last?
• Is it the same time every night, or within a window?
• Is it complete downtime (no response) or slow performance (timeouts)?

The answers point directly at the cause.

Cause 1: Cron Jobs Running at Midnight

Cron jobs default to running at midnight or at round-hour intervals. A poorly optimised cron job — a large database query, a full site re-index, generating all user reports at once — can consume enough CPU or memory to take the site down.

# List all cron jobs on the server
crontab -l
cat /etc/crontab
ls /etc/cron.d/
ls /etc/cron.daily/ /etc/cron.weekly/

# Check application cron jobs (Laravel example)
cat /etc/cron.d/laravel

Look for jobs scheduled around the time of the outage. Check what those jobs do — specifically whether they do database-intensive or memory-intensive work.

Fix: Stagger cron jobs away from midnight. Add resource limits. Optimise the slowest queries. Break large jobs into batches.

Cause 2: Database Maintenance Running During Business Hours' "Off Time"

Managed database services (RDS, PlanetScale, Supabase) sometimes schedule maintenance windows at night. If your database is briefly unavailable during maintenance, your application throws errors.

Check your database provider's maintenance window settings and see if they align with your downtime window.

Similarly, PostgreSQL's autovacuum can run aggressively on large tables during low-traffic periods — but if your tables are heavily bloated, an autovacuum run can lock queries temporarily. See how to monitor PostgreSQL performance for how to check autovacuum behaviour.

Cause 3: Backup Processes Consuming Disk or I/O

Nightly backups — database dumps, filesystem backups, log archiving — can saturate disk I/O, fill the disk temporarily, or spike CPU enough to affect web server response times.

# Check backup scripts timing
grep -r "backup\|dump\|archive" /etc/cron* /var/spool/cron/

# Check disk I/O during the outage window (if you have historical metrics)
# Or monitor it tonight:
iostat -x 1 10

If backups are creating 5–10GB database dumps on the same disk as your application data, I/O contention during the dump is a common culprit.

Cause 4: Log Rotation Restarting Your Web Server

logrotate runs daily and may be configured to restart or reload your web server after rotating logs. If it restarts rather than reloads, active connections are dropped. If the restart fails for any reason, the web server doesn't come back up.

# Check logrotate config for your web server
cat /etc/logrotate.d/nginx
cat /etc/logrotate.d/apache2

# Look for: postrotate scripts that restart (not reload) the server

Change restart to reload in the postrotate section to avoid dropping connections.

Cause 5: Memory Leak Reaching OOM Threshold

Application processes with memory leaks grow slowly over time. By midnight, after a full day of traffic, they've consumed enough RAM that the system's OOM (Out of Memory) killer terminates processes.

# Check OOM killer activity in system logs
dmesg | grep -i "oom\|killed process"
journalctl -k | grep -i oom

# Check memory usage trend
free -h
cat /proc/meminfo

If OOM events align with your downtime, you have a memory leak that grows throughout the day and gets killed at night when it finally exhausts available memory.

Using Monitoring to Pinpoint the Cause

The pattern that makes nightly downtime diagnosable is also what makes it fixable: it's predictable. Set up monitoring with 1-minute checks and review the exact timestamp of tonight's outage against your cron jobs, backup schedules, and maintenance windows.

Domain Monitor records every check — success and failure — with timestamps. When your site goes down at 02:17 for 8 minutes, you have a precise window to investigate. Create a free account.

Related Troubleshooting

• 521 vs 522 vs 524 Cloudflare Errors: What's the Difference?
• ERR_CONNECTION_TIMED_OUT Fix for Website Owners
• How to Monitor PostgreSQL Performance and Connection Issues
• Why Website Monitoring Misses Downtime Sometimes