PHP website monitoring and uptime

Uptime monitoring checks that the site responds before users write about it in a messenger. For a PHP script on a VDS, the mandatory minimum is an HTTP check of the home page and a couple of key URLs, an alert in Telegram/email, plus attention to disk space and SSL.

This is not APM with tracing of every SQL query. First learn that the site is down. Then go into logs.

What to monitor

• HTTP 200 on the home page.
• Login or admin page availability, without brute forcing.
• Response time: if 0.5s becomes 30s, that is also a signal.
• SSL certificate expiration.
• Disk space and inode count on the VDS.
• php-fpm / mysql process if there is an agent on the server.

External ping from two regions catches a provider outage. A local cron on the same machine will not notice a complete network outage.

Simple tools

UptimeRobot, Healthchecks, or your own cron with curl on another VPS all work. The important part is sending the alert where you actually look. An email to a mailbox nobody reads is useless.

curl -fsS -o /dev/null -w "%{http_code}" https://example.com/

If the code is not 200, send a notification. Do not check a heavy URL that hits the database every minute for no reason; the home page is often enough.

False positives

A short checker network glitch is not the same as a site outage. Confirmation helps: two failed checks in a row or a second node. Maintenance returning 503 is better excluded from alerts in advance if you return a proper maintenance code.

Basic auth on the admin panel makes the checker receive 401; either do not monitor the admin panel from outside or provide a separate health URL.

Disk and logs

The site can be "down" while HTTP still returns 200 if the disk is 100% full, errors are being written, and the cached home page still serves. Monitor df -h and inodes. nginx/php-fpm log rotation is mandatory. Backups filling the same disk are a common reason for sudden full disk: backup.

SSL and domains

An expired certificate breaks payments and some APIs. Alert 14 days before expiry. Issuance and renewal: SSL. After DNS changes, monitor the new IP.

Connection with script incidents

Uptime is green, but "the form does not send email" will not be caught by HTTP monitoring. For that, use application logs and cron: cron. A 500 on an internal page while the home page is live means you should add a second URL to checks.

PHP outage analysis: 500 error, database: MySQL. Server base: VDS, firewall. Sometimes after a bad ufw rule, "site unavailable" is seen by uptime first.

Who to wake

A night alert goes to someone who can log into the VDS. Product support by SLA responds to tickets but does not replace your infrastructure on-call: SLA, how to contact support.

Minimum implementation checklist

1. External check of the https home page every 1-5 minutes.
2. Alert to Telegram/email with the site name.
3. Disk check on the VDS once per hour through cron.
4. SSL reminder.
5. Once per quarter, test by stopping nginx on staging and confirming the alert arrives.

A local MicroServer usually does not need external monitoring. Production does. During migration to a new server, remember to switch checks to the new URL/IP: migration.

What to write in the alert

Site name, URL, response code, and time. Without this, at 3 a.m. you will not remember which of five VDS machines is down. For a team, include a runbook link: where to look at logs, how to restart php-fpm, and where to write to the hoster.

Do not duplicate the same alert into ten chats. Use one duty channel, otherwise everyone assumes someone else responded.

Check more than the home page

The home page may return 200 from cache while /login and /cart already return 500. Add one or two critical paths. Do not monitor 50 URLs every minute; you will create load and noise. For a board, a reasonable set is home page + login page + one random card if a stable URL exists.

Application errors: 500, database: MySQL.

SSL monitoring

Add a separate certificate-expiry check. Let's Encrypt certificates last 90 days; if cron renew is forgotten, browser clients will alert you before uptime does if you only check TCP. Configure renew and dry-run: SSL.

Disk, inode, backup queue

Cron script:

df -h / | tail -1
df -i / | tail -1

If used is above 90%, alert. Logs and old dump.sql files are common causes. Rotation and backup policy: backup. On shared hosting, limits are different; look at the panel, not df.

Synthetic checks versus server metrics

An external HTTP check answers "is it reachable from the internet". Node exporter, netdata, or a provider agent answers "why is CPU 100%". Start with external uptime; add machine graphs when there is time. For a PHP script on one VDS, this is enough for months.

Stack: VDS, Nginx, firewall. After a wrong rule, uptime turns red first.

Response to an alert - short order

1. Open the URL from a phone on another network.
2. If it is down, SSH and run systemctl status nginx php-fpm mysql.
3. Tail error.log.
4. Check disk with df -h.
5. If unclear, roll back to the latest backup if appropriate, or send a support ticket with the log: support.

Do not start with reboot as the only tool; you lose diagnostic state. Product SLA: SLA. Fresh installation as a last resort: installation.

It is also worth monitoring the disk queue for backups and logs: the site may answer 200 while mysql still writes, then an hour later it stops with a read-only or full disk. Connection with backup policy: backup. After moving to a new IP, update checks in the monitoring account the same day, not "when we remember": migration. If an alert is false because of your own firewall, check firewall and the provider security group. For a PHP application, a simple log alert on the word Fatal in error.log is also useful through an agent or grep by cron, but that is the second stage after external uptime. A support ticket with downtime facts: support.