Your Website Is Down: How to Read VPS Logs Before You Restart Everything

It is 9:12 in the morning.

A customer sends you a message:

The website is down.

You open the page and see a 502 Bad Gateway error.

The first instinct is often to restart Nginx, restart PHP, restart MySQL, or reboot the whole VPS.

Sometimes that makes the website return.

It can also erase the most useful clue you had.

A restart tells you that restarting helped. It does not tell you why the service failed.

Linux servers usually leave a trail. Web servers write errors. PHP records failures. MySQL reports crashes and startup problems. The operating system records service events. The challenge is knowing where to look and how to read only the few lines that matter.

This guide shows a practical method for troubleshooting a Linux VPS without trying random commands.

You do not need to be a Linux expert.

You need three things:

1. the approximate time when the problem started;
2. the name of the service involved;
3. a small group of commands for reading logs.

That is enough to solve a surprising number of hosting problems.

If you are deciding where to host this stack, compare our VPS plans with shared hosting. A VPS gives you operating-system control; our hosting comparison explains how that changes your administrative responsibilities.

First rule: do not reboot before collecting evidence

A reboot is not a diagnosis.

If the server is completely frozen or inaccessible, a restart may be unavoidable. But if SSH still works, take a few minutes to collect information first.

Before changing anything, record:

date
uptime
df -h
free -h

These four commands answer useful questions.

date confirms the server time.

uptime shows how long the server has been running and provides a quick view of load averages.

df -h shows disk usage.

free -h shows memory and swap.

A full filesystem can break applications even when CPU and RAM look fine. A server with almost no available memory may kill processes or behave slowly. A site that failed immediately after a reboot may have a service that did not start automatically.

Save the output somewhere before you begin making changes.

Start with the service status

Modern Ubuntu, Debian, AlmaLinux, Rocky Linux and many other distributions use systemd to manage services.

The command:

systemctl status SERVICE

gives you a quick view.

For Nginx:

sudo systemctl status nginx

For Apache on Ubuntu or Debian:

sudo systemctl status apache2

For MySQL:

sudo systemctl status mysql

A healthy service normally shows:

Active: active (running)

A failed service may show:

Active: failed

The status output often includes a few recent log lines.

Do not stop there.

The last five lines may show the final symptom but not the reason the problem started.

That is where journalctl becomes useful.

Meet journalctl

On systemd-based Linux systems, the journal collects messages from many services.

Ubuntu documents journalctl as the command used to print log entries stored by systemd-journald.

Running:

sudo journalctl

may produce thousands of lines.

That is rarely what you want.

The useful skill is filtering.

To view logs for Nginx:

sudo journalctl -u nginx

For MySQL:

sudo journalctl -u mysql

For SSH:

sudo journalctl -u ssh

The -u option filters by systemd unit.

Now the output is about the service you actually care about.

Show only recent logs

If the website failed ten minutes ago, you probably do not need logs from last month.

Try:

sudo journalctl -u nginx --since "30 minutes ago"

Or:

sudo journalctl -u mysql --since today

You can also use an exact time:

sudo journalctl -u nginx --since "2026-10-01 08:30:00"

This is one of the most useful troubleshooting habits you can develop.

Always connect the error to a timestamp.

If the customer says the problem started around 8:45, begin reading around 8:40.

Five minutes of focused logs are more useful than 50,000 unrelated lines.

Before investigating a service, check whether the hostname resolves to the intended server using our DNS lookup. This checks public DNS, not the health of Nginx, PHP or MySQL; use the server logs for those. Our nameserver and propagation guide helps distinguish DNS changes from an application outage.

Watch a log live

Sometimes the site is failing right now and you want to see what happens when you refresh the page.

For a systemd service:

sudo journalctl -u nginx -f

The -f option follows new messages as they arrive.

Press:

Ctrl+C

to stop.

This is especially useful when testing a configuration change.

Open the log in one SSH window.

Open the website in your browser.

Refresh the page.

Watch what appears.

The server often tells you exactly what it dislikes.

Traditional log files still matter

Not every useful message lives only in the systemd journal.

Web servers and applications commonly write traditional files under:

/var/log/

List the directory:

sudo ls -lah /var/log

You may see directories for Nginx, Apache, MySQL and other services.

The exact file names depend on your Linux distribution, software version and configuration.

Do not assume every VPS has identical paths.

Nginx logs

On many Ubuntu and Debian systems, Nginx commonly writes:

/var/log/nginx/access.log
/var/log/nginx/error.log

The access log records requests.

The error log is usually more useful when the website is broken.

Read the last 50 lines:

sudo tail -n 50 /var/log/nginx/error.log

Follow it live:

sudo tail -f /var/log/nginx/error.log

Search for a word:

sudo grep -i "error" /var/log/nginx/error.log

Search for a particular domain:

sudo grep "example.com" /var/log/nginx/error.log

A 502 error may show messages involving an upstream service, a Unix socket, PHP-FPM, or a connection being refused.

That immediately gives you a direction.

Apache logs

On Ubuntu and Debian, Apache commonly uses:

/var/log/apache2/access.log
/var/log/apache2/error.log

Read recent errors:

sudo tail -n 100 /var/log/apache2/error.log

On RHEL-family systems such as AlmaLinux or Rocky Linux, Apache is usually called httpd, and log locations often use:

/var/log/httpd/

This is why copying commands from a random tutorial without checking your distribution can create confusion.

First identify your operating system:

cat /etc/os-release

Then use paths appropriate to that system.

PHP-FPM logs

PHP problems often appear as web server errors because Nginx or Apache is waiting for PHP to answer.

First identify installed PHP services:

systemctl list-units --type=service | grep -i php

You may see something like:

php8.3-fpm.service

Then inspect it:

sudo systemctl status php8.3-fpm

And read recent logs:

sudo journalctl -u php8.3-fpm --since "30 minutes ago"

Your PHP version may be different.

Do not blindly type php8.3-fpm if your server runs another version.

PHP errors can also be written to application-specific or pool-specific log files depending on configuration.

If WordPress, WHMCS or another PHP application suddenly starts returning 500 errors, check both the web server log and PHP-FPM service logs.

A TLS warning needs a different investigation from a 502. Our SSL certificates page explains certificate options, and the CSR decoder can inspect the names and public key in a certificate request. It does not prove that the installed certificate is valid or trusted. For that workflow, read which SSL certificate you need.

MySQL logs

A website may look like a web server problem when the real issue is the database.

Check the service:

sudo systemctl status mysql

Then:

sudo journalctl -u mysql --since "30 minutes ago"

Common symptoms include:

• MySQL stopped unexpectedly;
• the disk is full;
• permissions prevent startup;
• a configuration change is invalid;
• memory pressure caused the process to be killed;
• the application has exhausted connections.

Log locations differ by distribution and configuration, so the journal is a good first stop.

If you want to learn how to install and manage a basic MySQL server, read How to Install MySQL on an Ubuntu VPS and Create Your First Database.

Learn four log-reading commands

You do not need a large command vocabulary.

Start with these.

tail

Show the end of a file:

tail -n 50 file.log

Follow new lines:

tail -f file.log

less

Open a large file without printing everything:

less file.log

Useful keys:

Space       next page
b           previous page
/word       search
n           next match
q           quit

grep

Find matching text:

grep -i "error" file.log

The -i makes the search case-insensitive.

You can search several useful terms:

grep -Ei "error|failed|fatal|denied" file.log

journalctl

Read structured service logs:

sudo journalctl -u nginx --since "1 hour ago"

These four tools solve a large percentage of basic VPS troubleshooting tasks.

What common HTTP errors are trying to tell you

The browser error is not always the root cause, but it helps you choose the first log.

403 Forbidden

The server received the request but will not serve the content.

Possible causes include:

• file permissions;
• directory permissions;
• web server access rules;
• missing index files;
• security rules.

Start with the web server error log.

404 Not Found

The server cannot find the requested resource.

Check:

• document root;
• URL rewrite rules;
• application routes;
• whether the file exists;
• whether the domain points to the expected virtual host.

500 Internal Server Error

The application or web server encountered an internal failure.

Check:

• PHP logs;
• application logs;
• Apache or Nginx error logs;
• recent configuration changes.

502 Bad Gateway

A proxy such as Nginx could not get a valid response from the upstream service.

Common examples include:

• PHP-FPM stopped;
• the PHP socket path changed;
• a backend application is down;
• connection permissions are wrong.

503 Service Unavailable

The service exists but cannot currently handle the request.

Possible causes include:

• application maintenance;
• exhausted workers;
• backend overload;
• a stopped dependency.

Use the status code as a signpost, not a final diagnosis.

A practical 502 example

Suppose the browser shows:

502 Bad Gateway

Do not reboot.

Start with:

sudo systemctl status nginx

Nginx is active.

Now:

sudo tail -n 50 /var/log/nginx/error.log

You find a message showing that Nginx cannot connect to the PHP-FPM socket.

Check PHP services:

systemctl list-units --type=service | grep -i php

Then inspect the service shown on your system.

For example:

sudo systemctl status php8.3-fpm

It is failed.

Now read:

sudo journalctl -u php8.3-fpm --since "30 minutes ago"

The log points to a PHP configuration error introduced during a recent change.

You now know what to fix.

If you had restarted the entire server first, PHP might have returned temporarily or failed again without you understanding why.

Logs turn guessing into evidence.

Check the disk before blaming the application

A full disk can produce strange failures.

Run:

df -h

Look for filesystems near 100 percent.

Also check inode usage:

df -i

A filesystem can have free gigabytes but no free inodes if it contains an enormous number of small files.

If /var, /tmp, or the root filesystem is full, applications may fail to create temporary files, logs, database files, PHP sessions, sockets, or package files.

Do not start deleting random files.

First identify what consumed the space.

For example:

sudo du -xh /var | sort -h | tail -n 30

Use disk-cleaning commands carefully on production servers.

Check memory when services disappear

Run:

free -h

Then search the kernel journal for out-of-memory events:

sudo journalctl -k | grep -Ei "out of memory|oom|killed process"

If Linux killed MySQL or PHP because the server ran out of memory, restarting the service may restore the site but will not solve the capacity problem.

You need to determine what consumed the memory.

The log shows the event.

Monitoring shows the trend.

Read around the first error, not only the last error

A common mistake is reading the final line.

Imagine this sequence:

09:02 Configuration file contains invalid directive
09:02 Service startup failed
09:03 Restart scheduled
09:03 Service startup failed
09:04 Too many restart attempts

The last line says too many restart attempts.

That is not the original problem.

The first line is.

When troubleshooting, look a little earlier than the obvious failure.

The cause often appears before the cascade of secondary messages.

Save evidence before editing

Before changing a configuration file, create a backup:

sudo cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.backup

Use configuration tests when software supports them.

For Nginx:

sudo nginx -t

For Apache on Ubuntu:

sudo apache2ctl configtest

A syntax test is much safer than restarting a production web server and hoping.

If the test fails, fix the configuration first.

Do not post full logs publicly

Logs can contain sensitive information.

Before pasting them into a forum, ticket, chat, or public issue, look for:

• IP addresses;
• usernames;
• email addresses;
• filesystem paths;
• database names;
• API tokens;
• authorization headers;
• session identifiers;
• query strings;
• customer data.

Share the minimum lines needed to diagnose the issue.

Never publish passwords, private keys, database credentials, or access tokens.

Build a simple troubleshooting routine

When a website fails, use the same order every time.

Step 1: confirm the symptom

Check the website from your browser.

Record the HTTP error and time.

Step 2: check the VPS

date
uptime
df -h
free -h

Step 3: check the relevant service

sudo systemctl status nginx

or the service you use.

Step 4: read recent service logs

sudo journalctl -u nginx --since "30 minutes ago"

Step 5: read application-specific logs

Examples:

sudo tail -n 100 /var/log/nginx/error.log
sudo tail -n 100 /var/log/apache2/error.log

Step 6: identify the first meaningful error

Search by timestamp.

Step 7: test the proposed fix

Use syntax or configuration checks before restarting.

Step 8: restart only the service that needs it

For example:

sudo systemctl restart nginx

Step 9: verify

Check:

sudo systemctl status nginx

Then load the website again.

Step 10: document what happened

Write down the cause and fix.

The next incident will be faster.