Why Is My Website Suddenly Slow?

Quick answer
Establish where the time goes before changing anything: DNS, TLS, server response, or client rendering. The fix depends entirely on which.
Sudden slowness with no traffic change usually means a resource filled up — disk, memory, connections — or a scheduled job is running.
Sudden slowness with traffic usually means a fixed limit was reached: connection pool, worker count, or a database that cannot keep up.
Check the four numbers first: CPU, memory, disk space, and database connection count. One of them is usually at its ceiling.
Change one thing at a time and re-measure; otherwise you will not know which change helped.

Why is my website suddenly slow?

The most common cause is a resource that has reached a limit — disk full, memory exhausted, connections saturated, or CPU pegged — because limits produce a cliff rather than a slope. A site is fine while a resource has headroom and becomes slow the moment it does not, which is exactly the sudden behaviour people describe. Traffic growth that pushes a pool over its maximum produces the same shape.

The second most common cause is a scheduled job interfering: a backup, an analytics aggregation, or a cron task that competes for the same disk or database and was always running but has grown with the data. Slowness that arrives at a regular time of day is almost always this, and it is the easiest to confirm from logs.

First, locate the slowness

Split the request into phases and find the slow one. DNS resolution, TCP connect, TLS handshake, time to first byte, and content download are all reported separately by a timing command, and each points at a different culprit. If time to first byte is high, the server or database is the problem; if download is slow, it is bandwidth or payload size; if connect or TLS is high, it is the network path or the certificate.

This step matters because the intuitive fix is usually at the wrong layer. Making the application faster will not help if the delay is before the request reaches it, and adding a CDN will not help if every request still waits on a slow query. One measurement eliminates most of the search space.

# Where does the time go? Run from outside the server, several times.
curl -o /dev/null -s -w \
  'dns %{time_namelookup}s  connect %{time_connect}s  tls %{time_appconnect}s  '\
  'ttfb %{time_starttransfer}s  total %{time_total}s\n' \
  https://example.com/

# Then, on the server: the four numbers that reach their ceiling.
uptime                       # load average vs core count
free -h                      # memory and swap
df -h /                      # disk space
ss -s                        # socket/connection totals

# And the database's own view of connections.
# psql: SELECT count(*), state FROM pg_stat_activity GROUP BY state;

Check the four resources that produce cliffs

Disk: a full disk makes writes fail or block, logs cannot rotate, and the database can stop accepting writes. Check not just the root filesystem but the volume holding data and logs, and look for something growing quickly — logs, uploads, or a backup left behind. Memory: if the process is swapping, every operation slows dramatically at the same time, which looks like a universal slowdown. CPU: a pegged core from an infinite loop, a regex backtracking, or a runaway job makes the whole application queue behind it.

Connections: the most common application-level ceiling. A pool with a fixed maximum, a database with a connection limit, or file descriptors exhausted at the operating system level all behave the same way — requests wait, latency climbs, and nothing reports an error until requests start to time out. The connection pool and database guides cover the exhaustion pattern specifically; this is where you check whether it is happening.

Then check what changed

Something changed, even if you did not. A deploy, a dependency update, a configuration change, a new cron job, a certificate renewal, or a data volume that crossed a threshold. Ask what is different rather than what is wrong: the deploy log, the version history, and the last configuration change are the fastest routes to the cause. Sudden slowness correlates with an event, and the event is usually recorded.

If nothing changed on your side, look outward: a third-party API your site calls, a DNS provider, a CDN edge, or the database provider. Measure the dependency directly rather than through your application, so you can tell whether the delay is yours or theirs. This is also why an external health check that runs continuously is valuable — it tells you when the change happened, not just that it did.

Where this bites vibecoders
Generated code rarely includes the ceiling-awareness that prevents these cliffs: pools are sized by default, caches are unbounded, logs are never rotated, and queries are written per-row. The site runs well until one of those defaults is reached, then falls off the edge. When debugging, look for a fixed number in the configuration — pool size, worker count, max connections — and check how close to it the system is running.

Where AI coding assistants get this wrong

Changing application code before measuring which phase is slow.
Adding a CDN for a problem caused by a slow database query.
Ignoring disk space because the site is ‘up’ — a full disk makes many things slow before it makes them fail.
Sizing a connection pool larger without checking the database’s connection limit.
Assuming nothing changed when the deploy log records a change.
Tuning multiple things at once and losing the ability to attribute the improvement.

Checklist

Measure DNS, connect, TLS, time to first byte, and total separately.
Check CPU, memory, swap, disk space, and open connections.
Compare current load against core count.
Check database connection counts against its limit.
Review deploys, dependency updates, and cron schedules for recent changes.
Change one thing, then re-measure the same way.

FAQ

Why did my site get slow with no increase in traffic?

Something reached a limit or something new started running. The usual candidates are a full disk, a process swapping to memory, an unbounded cache or log directory growing, or a scheduled job that now takes longer because the data is larger. Check resources for a ceiling and the schedule for recent activity before looking at the code.

How do I tell whether the server or the database is slow?

Look at time to first byte from outside, then at the server’s own timing for the request. If the application spends most of its time waiting on the database, the query is the problem; if it spends it in application code, that is the problem. Slow query logs and an application-level trace with spans give the same answer with more detail.

Could a slow third-party API be the cause?

Yes, and it is easy to miss because it looks like your site is slow. If any request depends on an external service synchronously, its latency becomes yours. Measure the dependency directly — independently of your app — and consider a timeout and a fallback so a slow dependency degrades rather than stalls.

What should I look at first if the whole site is slow?

Memory and swap. When a process swaps, everything it does slows down at once, which matches a site-wide symptom better than a specific slow endpoint. Run the memory report and check swap usage; if it is being consumed, that is your first fix, whether by adding memory or by finding what grew.