ST Site Triage
Showing commands for:
How do I tell which one?

? What does this error mean?

Paste the error message or log line you're seeing. We'll match it against common patterns and explain what it means.

0 Is this a Plesk server?

Plesk is a hosting control panel — it changes where files live, where logs are stored, and how services are managed. Find out before you start, because the commands below differ.

Quickest way to tell

  • Try opening https://<server-ip-or-hostname>:8443 in a browser. If a Plesk login screen appears, it's Plesk.
  • SSH to the server and run the command below. If the directory exists, it's Plesk.
ls /usr/local/psa/version 2>/dev/null && echo "PLESK" || echo "no plesk"

If unsure, just ask the customer: "Do you log into a control panel called Plesk to manage the website, or do you connect by SSH directly?"

1 Does the domain resolve to an IP?

DNS is the system that turns a domain name (like example.com) into the IP address of the server hosting it. If DNS isn't returning an IP, the customer's browser can't even reach the server — nothing else matters until this works.

Quick DNS check

Check the A record

dig +short example.com A
Good: one or more IP addresses appear, e.g. 87.106.96.230.
Broken: no output, or the wrong IP (pointing to an old host).

Check name servers

dig +short example.com NS

If no name servers come back, the domain may have lapsed or the registrar isn't delegating it. Ask the customer to check their domain registrar.

Trace the chain from the root

dig +trace example.com

This walks DNS from the root servers down. Useful when the answer is cached or you suspect a delegation issue.

What to tell the customer: "Your domain isn't resolving to a server right now. This usually means the domain's DNS settings need updating at your domain registrar. Could you log into where you bought the domain and check the A record points to <server-ip>?"

If DNS works → go to step 2. If not, the problem is at the DNS layer — there's no point checking firewall, ports, or logs yet.

DNS still failing? Check these next:
  • Domain expired? A lapsed domain often returns no records at all. Check the registrar's WHOIS or admin panel.
  • Wrong name servers? If NS records don't point at the host's name servers, the records you set up will never be authoritative.
  • Recent change not propagated? Updates can take up to 24 hours. Use a public resolver like dig @8.8.8.8 example.com to bypass local caching.
  • DNS resolves to the wrong IP? Old A record from a previous host. Update it at the registrar to point at the current server.

2 Is the server actually reachable?

DNS gave us an IP. Now: does the server answer at that IP at all? If the server is offline or the network is broken, every other check will fail.

Quick reachability check (ping + HTTP)

Ping the server

ping -c 4 <server-ip>

Some hosts block ping at the firewall. A failed ping doesn't always mean the server is down — but a successful ping is a strong "yes, it's alive".

Trace the route

traceroute <server-ip>

Shows the hops between you and the server. If it stops short, you've found roughly where traffic is being dropped.

If the server is reachable → go to step 3.

Server not reachable at all? Check these next:
  • Cloud security group / external firewall. AWS, Azure, DigitalOcean and others have a firewall in front of the server. The OS-level firewall on the server is a separate layer.
  • Is the server actually running? Check the cloud console / Plesk billing portal. The VM may have been stopped, suspended, or hit a billing issue.
  • Routing problem? Try reaching the server from a different network (your phone on mobile data) to rule out a local ISP issue.

3 Are the right ports open?

A web server listens on ports 80 (HTTP) and 443 (HTTPS). If a firewall is blocking those, the server is technically up but no one can reach the site.

Quick port check (from this server, public-internet view)

From your machine — is the port reachable?

curl -I https://example.com --connect-timeout 5

"Connection refused" means nothing is listening. "Connection timed out" usually means a firewall is silently dropping packets.

On the server — what's actually listening?

ss -tlnp | grep -E ':80|:443'

You should see nginx, apache2, or httpd listening on both :80 and :443. If nothing's listed, no web server is running — jump to step 4.

Check the firewall

sudo ufw status
sudo iptables -L -n | head -50
plesk bin firewall --get-rules

Look for rules that DROP or REJECT tcp/80 or tcp/443. On a cloud host (AWS, DigitalOcean, etc.), also check the cloud provider's security group — that's a separate firewall in front of the server.

If ports are open and listening → go to step 4.

Ports look right but customer still can't connect?
  • Listening on 127.0.0.1 only. Check the IP in ss -tlnp output — if the web server is bound to 127.0.0.1:80 instead of 0.0.0.0:80, no one outside the server can reach it.
  • Cloud security group blocks it. The OS firewall is open, but the cloud provider's firewall is dropping the traffic.
  • Different port entirely. Some apps run on :8080 or :8000 and rely on a reverse proxy that's now broken.

4 Is the web server running?

If ss showed nothing on :80/:443, the web server (NGINX or Apache) isn't running. This is one of the most common causes of an outage.

Find out which web server is installed

which nginx apache2 httpd 2>/dev/null

Check service status

systemctl status nginx
systemctl status apache2
Good: green "active (running)".
Broken: "inactive (dead)" or "failed". The output usually contains the line that caused the failure.

Test the config before restarting

sudo nginx -t
sudo apache2ctl configtest

Restarting with a broken config takes the site fully offline. Always test first.

Restart safely

sudo systemctl reload nginx
plesk repair web -y

In Plesk, the "repair web" command rebuilds the config for all subscriptions and restarts services.

If the web server is up → go to step 5.

Web server won't start at all?
  • Config syntax error. The output of nginx -t or apache2ctl configtest names the file and line. Fix that first.
  • Disk full. Services often fail to start if they can't write a PID or log file. Jump to step 5.
  • Port already in use. Another process grabbed :80 or :443 — check ss -tlnp | grep :80.
  • Recent package update. An OS update may have replaced a config file. Check journalctl -u nginx --since "1 hour ago".

5 Has the server run out of disk space?

A full disk silently breaks websites. Logs can't be written, sessions can't be created, databases refuse writes — and the symptoms look like a hundred unrelated problems.

Check disk usage

df -h

If any partition (especially / or /var) shows 100% Used, that's almost certainly your problem.

Check inodes — the often-missed sibling

df -i

An inode is a slot for a file. You can be at 100% IUse% with disk free if a directory has millions of small files (a runaway log, session files, mail spool). Same effect — the system can't create new files.

Find what's eating the disk

sudo du -sh /var/* 2>/dev/null | sort -h | tail -10

Common culprits: /var/log (a runaway log file), /var/lib/mysql (a database without a quota), or in Plesk /var/www/vhosts/<domain>/logs.

If disk and inodes are healthy → go to step 6.

Disk fills up again right after you free space?
  • Runaway log file. Find the largest file with sudo find /var/log -size +500M. Rotate or truncate it, then fix what's writing so much.
  • Failed backup writing forever. Check /var/lib/psa/dumps on Plesk for orphaned backup attempts.
  • Spam mail queue. A compromised mail account can fill the queue fast — check postqueue -p | tail.

6 PHP / application layer

The web server is up but the page shows a blank screen, a 500 error, or "PHP Fatal error". The web server is fine — the application running behind it isn't.

Page content scan

Fetches the page and looks for common error markers: WordPress DB errors, default Apache/NGINX/Plesk pages, "site suspended", maintenance mode, directory listings, etc.

Is PHP-FPM running?

systemctl status php8.2-fpm
systemctl status plesk-php84-fpm

Plesk runs its own PHP versions under /opt/plesk/php/ with services named plesk-php74-fpm, plesk-php83-fpm, etc. Each subscription can use a different version.

Check the PHP version a site is using

plesk bin site --info example.com | grep -i php

Run PHP from the command line to catch syntax errors

php -l /path/to/file.php

If PHP is healthy and the site still misbehaves → read the logs.

PHP-FPM keeps dying or restarting?
  • Out of memory. Check dmesg | grep -i "killed process" for OOM kills. Likely a memory issue, not PHP itself.
  • Worker pool exhausted. Symptom: site hangs under modest load. Increase pm.max_children in the FPM pool config.
  • Wrong PHP version selected. In Plesk, the subscription may be set to a PHP version that's no longer installed. Check PHP Settings on the subscription.

7 Read the error logs

The logs almost always tell you exactly what's wrong — once you know where to look. There are usually three log layers, and the order to check them is: web server access log → web server error log → application/PHP error log.

Plesk log locations

sudo tail -100 /var/www/vhosts/<domain>/logs/error_log
sudo tail -100 /var/www/vhosts/<domain>/logs/access_ssl_log
sudo tail -100 /var/log/plesk-php84-fpm/error.log

Plain Linux log locations

sudo tail -100 /var/log/nginx/error.log
sudo tail -100 /var/log/apache2/error.log
sudo tail -100 /var/log/php8.2-fpm.log

Watch live as you reproduce the error

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

Ask the customer to refresh the page while you watch. The line that appears at that moment is the one to read.

Common log lines and what they mean

You see…Likely meaning
connect() to unix:/run/php/php-fpm.sock failedPHP-FPM isn't running, or the socket path in NGINX config is wrong.
Permission denied on a file pathWeb server user (www-data / nginx) doesn't have read access to the file.
No space left on deviceDisk or inodes full → back to step 5.
SSL_do_handshake() failedTLS issue → step 8.
upstream prematurely closed connectionThe app behind NGINX (PHP-FPM, Node, etc.) crashed mid-request.
504 Gateway Time-outUpstream is too slow (database query, external API). Check what the app is doing.
Logs are silent or unhelpful?
  • Wrong log file. Plesk has per-domain logs in /var/www/vhosts/<domain>/logs/ that are separate from the global ones. NGINX-as-reverse-proxy in front of Apache means errors might be in either.
  • Log level too low. Default is usually warn or error. Temporarily raise to debug in the NGINX/Apache config to capture more.
  • App logs to its own file. Many CMSes (WordPress, Laravel) write to their own log inside the application directory — wp-content/debug.log, storage/logs/laravel.log.
  • Try the lookup tool above. Paste an exact log line into the error message lookup at the top of this page.

8 SSL / TLS issues

"Your connection is not private", padlock with a warning, or the page works on http:// but not https://. Three things go wrong with TLS: the certificate is expired, the certificate is for the wrong domain, or the chain is incomplete.

Quick TLS / certificate check

What does the certificate actually say?

echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -subject -issuer -dates

You'll get the certificate's subject (which domain it's valid for), issuer (who signed it), and validity dates.

Is the chain complete?

curl -vI https://example.com 2>&1 | grep -E '(SSL|certificate|verify)'

"unable to get local issuer certificate" means the server is sending its certificate but not the intermediate cert that links it to a trusted root. Browsers will warn — fix by reinstalling the cert with the full chain.

Renew Let's Encrypt (Plesk)

plesk bin extension --exec letsencrypt cli.php --renew -d example.com

Renew Let's Encrypt (certbot, plain Linux)

sudo certbot renew --force-renewal --cert-name example.com
TLS works but customer still sees a warning?
  • Mixed content. The page loads over HTTPS but pulls images, scripts, or stylesheets over HTTP. Browsers block these. Check the browser's developer console (Network tab).
  • HSTS pinned old cert. If a previous visit pinned strict transport security, browsers may refuse the new cert until the pin expires. Test in incognito / a different browser.
  • Let's Encrypt renewal fails repeatedly. Usually because port 80 is blocked (HTTP-01 challenge needs it open) or DNS for the domain doesn't point at the server.

9 Plesk-specific gotchas

Issues that only appear when Plesk is in the mix.

Subscription suspended

A suspended subscription returns a Plesk-branded "this site is suspended" page. The site looks broken to the customer, but everything below is working perfectly.

plesk bin subscription --info example.com | grep -i status
plesk bin subscription --activate example.com

Hosting settings disabled

In Plesk → Subscriptions → <domain> → Hosting Settings, "Web hosting" can be toggled off without deleting the site. Looks identical to a network outage.

Repair the web stack

plesk repair web example.com

Rebuilds the per-domain NGINX/Apache config from Plesk's database. Fixes most "everything looks right but it doesn't work" cases.

Reload all services

plesk repair installation

Where to look in the Plesk UI

  • Tools & Settings → Services Management — start/stop NGINX, Apache, PHP-FPM, MySQL.
  • Tools & Settings → Server Health Monitor — quick view of CPU, memory, disk per partition.
  • Subscription → Logs — per-domain access and error logs without needing SSH.
  • Subscription → SSL/TLS Certificates — issue, renew, or replace certificates.

Quick reference: HTTP status codes

What the customer's browser is getting. The first digit tells you who's at fault.

CodeMeansWhere to look
200OK — page loaded.Site is working.
301 / 302Redirect.Check the redirect chain — could be a loop.
403Forbidden — server understood, refused.File permissions, .htaccess, or web app auth.
404Not found.Wrong document root, missing file, or broken rewrite rule.
500Generic server error.Always read the application/PHP error log — step 7.
502Bad gateway.Web server is up; the thing behind it (PHP-FPM, Node) is down.
503Service unavailable.Server is overloaded, in maintenance mode, or out of workers.
504Gateway timeout.App is too slow — usually a stuck database query or external API call.