Checking the site is really working

Pointing an uptime monitor at the home page proves less than it looks. Pages are served from a full-page cache, so an anonymous visitor can be given a perfectly good copy while the database is unreachable behind it. Every serious incident this platform has had was invisible to a plain 200 check.

The /health endpoint

Open /health on your site. In a browser it shows a status card; anything asking for JSON gets JSON. It reports whether the database answers, whether migrations have run, whether a mail transport is configured at all, and how many errors have been logged.

It returns 503 when something is wrong, so a monitor can act on it. A check that always answers 200 never pages anyone.

Setting up a monitor

1. Create a free account with an uptime service.
2. Add a keyword monitor, not a plain HTTP one, pointing at https://yoursite.com/health.
3. Set the keyword to "status":"ok" and alert when it is absent.

Keyword rather than HTTP, because a site can be degraded and still answer 200 for other reasons. The keyword only appears when every check passed.

The error log

Errors appear on the Admin dashboard, and that includes failures the site handled and carried on from: a message that could not be sent, a query that fell back to zero. Those used to be invisible, which is how faults survived for months.

The log is at storage/logs/error.log. When it fills it is renamed aside rather than trimmed, so nothing is lost, and the last ten are kept. Both the current log and the archives can be downloaded from the dashboard, which matters because some control panels will not let you reach that folder at all.

Reading a long list

A large number is usually one fault repeating, not many faults. Look at what the entries say before counting them. One misconfigured integration retrying every few minutes will fill a log by itself, and the fix is one setting rather than a hundred.