Linux Server Slows Down at the Same Time Every Day? 12 Checks

Write down when the slowdown begins, when it ends, and which service is affected. Do not settle for “around midnight.” A ten-minute difference can separate a backup task from a database operation.

Check the server’s current time and time-zone configuration:

date -Is
timedatectl

Compare this with the timestamps in application dashboards, provider graphs, and monitoring alerts. Some systems use UTC while others display local time.

For example, 02:00 UTC is not necessarily 02:00 in the application dashboard’s configured time zone.

A number has little meaning without context. A load average of 4 may be ordinary for one system and concerning for another. Similarly, low unused RAM does not automatically mean memory exhaustion.

During a normal period, record a basic snapshot:

uptime
nproc
free -h
df -h

Repeat the same inspection during the slowdown when possible. Compare the results with application response times and any previously collected monitoring data.

These commands do not show last night’s exact CPU or memory state when run the next morning.

For a broader introduction, see the Linux Server Health Check Checklist. This article goes further by investigating short-lived incidents that a general health check may miss.

Recurring slowdowns often raise suspicion about scheduled workloads. Check what is configured to run near the incident window, but do not assume that every scheduled job actually executed.

crontab -l

ls -ld /etc/cron.*

If you have authorized administrative access, inspect the root crontab and relevant system configuration. Remember that individual service accounts can have their own crontabs.

systemctl list-timers --all

User-level systemd timers are separate. For the current login account, they can be inspected with:

systemctl --user list-timers --all

Review the timer schedule and the service it activates. Some systemd timers can run later than the nominal calendar time because of accuracy windows or randomized delays. The NEXT and LAST columns alone are not a complete historical execution record.

Our Cron vs systemd Timers lesson explains how these schedules work and why actual execution times can differ from the expected time.

The problem may not be one expensive job. It may be several ordinary jobs running together.

Consider a backup reading large amounts of data while a database performs maintenance and a package manager writes updated files. Each task might finish comfortably on its own but compete for the same storage or CPU resources when their schedules overlap.

Inspect relevant automation logs and the provider’s backup or snapshot history. Include external systems: a hosting-provider snapshot might not appear in your guest operating system’s crontab.

For systemd-managed jobs, find the service associated with a suspected timer:

systemctl cat example.timer

The name example.timer is a placeholder. Use the actual unit discovered on your server.

Load average is not a percentage of CPU utilization. On Linux, it reflects runnable tasks and tasks in uninterruptible sleep, so a high load value can be associated with more than CPU competition.

If the optional sysstat tools are installed and historical collection was already enabled, inspect CPU activity during the incident.

sar -u -s 01:45:00 -e 02:30:00

Without -f, sar normally reads the current day’s recorded statistics. For an earlier date, locate the correct archived data file and supply it using -f. Archive locations vary by distribution.

If statistics were not recorded, the command cannot reconstruct the missing interval. During a future incident, a short live sample can be taken:

sar -u 1 5

Compare the CPU fields, including user, system, idle, I/O wait, and steal time where available. A busy CPU, high I/O wait, and high virtual-machine steal time suggest different follow-up investigations.

A filesystem can have plenty of free capacity while applications wait for storage operations to complete.

During the slowdown, if iostat from sysstat is available, collect a small number of live reports:

iostat -x -y 2 4

The -x option requests extended statistics. The -y option skips the initial since-boot report, leaving interval-based samples.

Review read and write await values, outstanding requests, throughput, and device utilization. Output columns can vary between tool versions.

A high %util value does not universally prove saturation on modern SSDs or parallel storage systems. Correlate device metrics with application latency and I/O pressure instead.

If historical disk collection was enabled, sar -d can help examine the relevant interval. Otherwise, live commands cannot reveal yesterday’s short storage spike.

Filesystem capacity is a different question. If a task fails with an out-of-space error, use df and du to inspect Linux disk usage.

Memory usage is not the same as memory pressure. Linux uses otherwise available RAM for cache, and low free memory can be normal.

During the affected period, inspect memory availability and virtual-memory activity:

free -h
vmstat 1 5

In vmstat, the first report typically summarizes values since boot; focus on subsequent interval reports for live activity. Watch the swap-in and swap-out fields, along with the broader system state.

On Linux systems that expose Pressure Stall Information, inspect:

cat /proc/pressure/memory

The avg10, avg60, and avg300 fields describe recent pressure windows, not an archive of last night’s event. A file may be absent on systems without the interface.

Also review OOM-related messages in the incident logs. An OOM event is important evidence, but not every slowdown involves an OOM kill.

See Linux Memory Explained for the distinction between RAM, cache, swap, and genuine memory pressure.

On a virtual server, the guest operating system may sometimes wait while the hypervisor schedules physical CPU time for other work.

Where supported, this can appear as CPU steal time. If mpstat is installed, sample it during the affected interval:

mpstat 1 5

Look for the %steal field. Historical sar -u data may also include steal time.

A sustained increase during the slowdown can justify investigating host contention or CPU allocation, but it does not by itself identify another tenant or prove that the VPS provider is at fault.

Compare the finding with provider metrics, instance limits, and application performance before escalating.

Searching all available logs can produce thousands of irrelevant entries. Use the established incident window to limit the investigation.

The following date and time are illustrative. Replace both timestamps with the actual incident window in the server’s relevant time zone.

sudo journalctl \
  --since "2026-01-15 01:45:00" \
  --until "2026-01-15 02:30:00" \
  --no-pager

If you suspect a systemd service, query that unit specifically:

sudo journalctl -u nginx.service \
  --since "2026-01-15 01:45:00" \
  --until "2026-01-15 02:30:00" \
  --no-pager

Use nginx.service only if it is the service you actually need to investigate. Other applications may record logs elsewhere, including files, container logging systems, or external platforms.

Look at messages before the failure, not only the final error. A database timeout, an OOM kill, and a maintenance job start may occur close together without sharing the same cause.

Our journalctl troubleshooting guide explains how to narrow systemd logs by unit, time, and priority.

A server-wide performance incident and a slow application are not necessarily the same problem.

If operating-system metrics remain ordinary while a website slows down, examine the application’s own request timings, worker queues, database queries, and external dependencies.

For a safe, authorized HTTP health endpoint, a single request can measure end-to-end response time from the client:

curl -sS -o /dev/null \
  -w 'HTTP %{http_code} total=%{time_total}s\n' \
  https://example.com/health

Use a real endpoint designed for health checks. Do not repeatedly load-test a production application just to reproduce a problem.

Compare application latency against database metrics, connection-pool waits, cache behavior, background workers, and external API timing where those measurements are available.

If the incident has already ended and no historical metrics exist, you may not be able to establish the cause from the available evidence.

That is a visibility problem, not a reason to invent an explanation.

First, determine whether historical collection is already configured:

command -v sar
command -v pidstat
ls -ld /var/log/sa /var/log/sysstat 2>/dev/null

These locations are common but distribution-dependent. The presence of a directory does not prove that current statistics are being collected, and a missing directory does not exclude an alternative monitoring system.

During the next incident, if pidstat is installed, a short live sample can help identify tasks consuming CPU, memory, and I/O resources:

pidstat -dur 1 5

The sample covers only the period while the command is running. It cannot identify a process that finished hours earlier.

For future incidents, configure a suitable existing monitoring system to retain timestamped CPU, memory, disk, and application-latency measurements. Choose a sampling interval short enough to capture the incident, accounting for monitoring overhead and retention cost.

On a server without historical monitoring, enabling sysstat data collection can be useful, but it is an operational configuration change. Review the distribution’s supported setup and retention policy before enabling it.

Once you have a credible explanation, decide whether a change is justified and how to verify it.

For example, if two maintenance jobs overlap and storage latency increases at the same time, staggering those jobs may be worth testing. But the decision should account for backup requirements, dependencies, and the production change process.

Before making a change:

1. Record the evidence supporting the hypothesis.
2. Identify the smallest relevant configuration change.
3. Back up the affected configuration.
4. Confirm compatibility and rollback steps.
5. Apply the change through the supported mechanism.
6. Observe the next comparable incident window.

Compare application latency and the suspected resource metric against the prior baseline. If the timing changes but the slowdown persists, revisit the hypothesis.