Features · Keep operations running
Know whether the site is up, slow, or out of room.
Uptime from outside, request time and PHP errors from inside, and the server underneath, read from PHP with nothing to install. Every reading says what it measured, so a shared server’s load is never mistaken for your site’s.
On every plan, Watch (free) includedWatch: uptime every 5 minutes. Monitor: every minute, request time and PHP errors. Insight: server resources.
A site can answer and still be failing
The home page loads, so an uptime checker is happy. Meanwhile checkout requests take four seconds, a plugin is logging a warning on every page, and the server’s PHP code cache filled up last month and has been recompiling ever since.
- Customers say the site is slow; the uptime report says 100 %.
- Errors pile up in a log nobody opens.
- The host says the server is fine, and nobody can show otherwise.
What you can see
Uptime, from outside and inside
The site’s public address and the plugin’s own probe are checked every minute (Watch: the public address every 5 minutes). Two checks tell a site that is down apart from one a cache or CDN is still serving.
Downtime leads any incident it is part of.
| check | every | last answer | status |
|---|---|---|---|
| Public address | 1 min | 200 in 0.31 s | up |
| Plugin probe | 1 min | 200 in 0.12 s | up |
Request time by surface
One PHP request in fifty is timed on the server, and the storefront, wp-admin and AJAX/REST are each judged against their own normal. A storefront alert needs an average of 5 seconds held for 30 minutes, so one slow page is not a slow store.
This is the time PHP spends on a request, not how long a browser takes to draw the page.
The server under it, labelled
On Insight, the plugin reads load, CPU, memory, disk and database status from inside PHP, as the web user. Each reading says whether it describes the site’s container, a server it has to itself, or a shared server.
It also reads OPcache, the PHP code cache, and the PHP-FPM pool: a cache too small for the site’s code, or a pool that has run out of workers.
- memory
- 61 % — this container’s memory, of its 2.0 GB limit cgroup
- load
- 3.4 on 8 CPUs — the host’s load, not this account’s shared
- database
- 12 / 151 connections — the server’s, not this site’s own shared
- disk
- 71 % used, 14.2 GB free — the filesystem the site lives on host
A reading you can hand to the host
When the server is the problem, the alert says which number and whose number it is.
Scope: this server’s PHP. Read on the plugin’s regular run, not in a visitor’s request.
The day’s fatal PHP errors also arrive in the morning digest, by fingerprint, new ones first.
See it in a real store: a code cache full for years.
Coverage and limits
What it covers
- Uptime. The public address and the plugin’s own probe, every minute; every 5 minutes on Watch.All plans
- Request time by surface. The storefront, wp-admin and AJAX/REST each judged against its own normal, from a 2 % sample of requests.Monitor
- PHP errors. PHP errors by class with redacted messages, and the day’s fatal errors in the morning digest.Monitor
- Server resources. CPU, load, memory, disk and database status, each reading labelled with whose numbers they are. Nothing to install.Insight
- OPcache and the PHP pool. A PHP code cache too small for the site’s code, a PHP pool that is full, and the PHP error log’s counts.Insight
Limits
- Request time is PHP time on the server, sampled. It is not browser rendering time and not a page-speed score.
- A page served from a cache never reaches PHP, so it is not timed or counted.
- On a shared server, load and database figures include other sites. They are labelled “shared”; your share is never guessed.
- Web-server access logs and syslog are not read. Of the logs, only the PHP error log’s counts and redacted samples.
How each reading is taken
- Uptime is checked from our side. The probe is the plugin’s own endpoint, so a cached front page cannot hide a broken PHP.
- Request time: one request in fifty, timed in PHP. The uptime probe and WP-CLI are never sampled. wp-admin and AJAX/REST never go above warning; the slowest request per surface is kept as a reading, never as a problem.
- Host readings come from
/proc, the cgroup files, free disk space,SHOW GLOBAL STATUSandopcache_get_status(), within a two-second budget per run. A reading that cannot be read (Windows,open_basedir, a disabled function) says why.
The host, with nothing installed · PHP error log reader (free)
Start using it
- Install the plugin from wordpress.org. It is read-only: it cannot change the site.
- Pair the site with the token from your dashboard. Setup, step by step
- Uptime starts at pairing. Request-time judgements start once each surface has 48 hours of its own normal.
All plans On every plan, Watch (free) included. Watch: uptime every 5 minutes. Monitor: every minute, request time and PHP errors. Insight: server resources. Compare plans
Questions
Do I need to install anything on the server?
No. Everything is read from inside PHP by the WordPress plugin. There is no agent, daemon or root access.
Is this a page-speed test?
No. It times real requests in PHP on the server. It does not load pages in a browser or score front-end performance.
Which plan has what?
Uptime is on every plan (Watch: every 5 minutes). Every-minute uptime, request time and PHP errors are on Monitor. Server resources, OPcache and the PHP pool are on Insight.
My host shares the server. Are the numbers useful?
Yes, labelled as the server’s. A server at load 40 is still why the site is slow; the alert says it is the server’s figure, not your site’s.