Diagnose VPS incidents with journalctl, resource checks and external probes

Monitoring should answer two different questions: can a user reach the service, and what is happening inside the server when they cannot? A CPU graph alone does not prove availability, while a failed HTTP request does not explain whether the cause is DNS, TLS, a full disk or an application error. Combine an outside probe with a small set of host checks and a consistent incident timeline.

Capture a timestamped system snapshot

date -Is
uptime
free -h
df -h
df -i
systemctl --failed

Compare load with the server's available CPUs and workload rather than treating one fixed load number as universally unhealthy. In free output, available memory is more useful than assuming that all filesystem cache is wasted RAM. Check both storage capacity and inode usage: many small files can exhaust inodes even when byte capacity remains.

Record when symptoms began, which users or locations are affected and the last deployment or maintenance change. Do not restart every service before collecting a useful failure message. A restart can change the evidence and may only hide a recurring resource or configuration problem.

Use the journal with a specific service and time range

systemctl status nginx.service --no-pager
sudo journalctl -u nginx.service --since '1 hour ago' \
  --until 'now' -n 150 --no-pager
sudo journalctl -p err --since '1 hour ago' --no-pager
sudo journalctl --disk-usage

Replace nginx.service with the unit that actually runs your application or proxy. Filter by a narrow incident window and correlate a restart, bind failure or permission error with the user-visible event. A unit can be active while an application dependency fails, so read application and database logs as well.

Check how long the journal and rotated application logs are retained. Persistent logging and rotation policy differ by image. Do not solve disk pressure by deleting logs before preserving the relevant incident evidence, and do not assume the journal is a permanent archive.

Probe the service from outside the VPS

curl --fail --silent --show-error \
  --connect-timeout 5 --max-time 15 \
  -o /dev/null \
  -w 'status=%{http_code} ip=%{remote_ip} dns=%{time_namelookup}s connect=%{time_connect}s tls=%{time_appconnect}s first_byte=%{time_starttransfer}s total=%{time_total}s
' https://example.com/

The timing values are cumulative milestones, not independent durations to add together. A high first-byte time can include connection setup and server work; compare representative samples rather than assigning blame from one measurement. The resolved IP is useful when DNS, a CDN or multiple backend addresses are involved.

Choose what the probe should prove. A cached home page may be enough for a basic public availability check, but it may not exercise database writes or background jobs. A health endpoint should intentionally expose only a minimal health result, not configuration secrets or private diagnostic data.

Connect graphs to a concrete question

The Control Panel's Statistics page provides CPU, memory, network and disk I/O history across selectable time ranges. Compare those trends with the incident timestamp and the workload: increased traffic with stable response times is different from increased disk I/O alongside database timeouts.

sudo ss -lntup
sudo journalctl -k --since '1 hour ago' -n 100 --no-pager

Kernel messages can reveal out-of-memory events or storage problems that are not visible in an application's own log. A high memory figure alone is not enough to conclude that the kernel killed a process. Look for evidence, then decide whether the correction is a resource increase, a leak fix, query tuning or a traffic-control change.

Design alerts that lead to an owned response

Run public availability probes from a location outside the VPS and send failures to someone who can respond. A scheduled curl command that discards errors is a check, not a complete alerting system. Define a reasonable retry and escalation policy so a single transient failure does not create unnecessary pages while a sustained outage remains actionable.

Set resource alerts around sustained pressure and capacity trends. Track backup failures and certificate expiry separately from HTTP availability. Local monitoring can fail with the server itself, so an independent observer and a documented contact route are important. Verify notification delivery with a controlled test, not an assumption.

Close incidents with evidence and a follow-up action

After a repair, rerun the external probe, confirm the affected application workflow and review the relevant service logs. Record the cause you established, the change you made and how you verified recovery. If you only know that a restart helped, record that uncertainty instead of inventing a root cause.

• Use a consistent timezone or include an offset in incident notes.
• Redact access tokens, cookies, customer addresses and private paths before sharing logs.
• Keep retention and access rules proportionate to the data in the logs.
• Turn repeated incidents into a tracked maintenance or capacity task.

Primary documentation

• systemd journalctl reference
• curl command-line reference
• Ubuntu security updates