Monitoring
Monitoring means someone notices a problem before your customers tell you. This page describes what good monitoring of an Exponential site looks like from the owner's chair, and what to ask the host or operator who sets it up. The technical detail is in Health checks and monitoring and, for hosts, Monitoring overview.
No single health address
The installation book is direct: "There is no single health URL; combine a check from outside with the status commands inside" (Health checks and monitoring). Ask for both halves.
From outside: what customers see
An external uptime service checks two addresses (Health checks and monitoring):
| Check | Healthy answer | Why |
|---|---|---|
| The front page over HTTPS | 200, in a time you know | What visitors reach first |
| The administration sign-in page | 200 | It goes through the application, while the front page may come from a cache |
During planned maintenance the site answers 503 with a Retry-After header; the monitor should be paused for the
window or accept that answer (Maintenance mode and planned work).
On the server: why it is failing
The host runs status commands on a schedule and alerts when one fails: the platform health check, the cache status, the Velocity status where Velocity serves the site, the audit trail verification, cron and free disk space. Each gives a clear healthy or unhealthy answer (Health checks and monitoring). You do not need to run them; ask that they are scheduled and that a failure reaches a person.
Pages a person reads each week
| Page | What it shows |
|---|---|
| Setup > System information | Which server answered, health checks with what to do, versions, database, cron, mail |
| Setup > Log files, log health and error digest | Disk used by logs, the distinct errors of the last 24 hours |
| The Audit tab | The state of each audit channel, recent events, alerts |
| Setup > Cronjobs | Scheduled jobs, last runs, jobs that need attention |
Source: Health checks and monitoring. If nobody on your team reads them, ask your host or partner for a short weekly or monthly summary instead (Monthly operations includes a report to the customer).
Who is woken up
"A check nobody reads is not monitoring" (same page). Decide and write down:
- To do: Who receives an alert in office hours, and who outside them; who is the deputy.
- To do: How fast they are expected to look (Contracts and SLAs).
- To do: Where alerts go: mail, a chat channel, a phone.
- To do: Who receives the audit trail's own alert mail (brute-force sign-ins, an administrator role granted, the audit switched off); the host can list the recipients (The audit trail).
- To do: When the owner is told, and by whom.
Questions for your host
- Which addresses do you check from outside, how often, and from where?
- Which status commands run on the server, and what happens when one fails?
- Who receives alerts outside office hours?
- Where Velocity serves the site: is its watchdog installed, which starts it again when it is down (Health checks and monitoring)?
- Can we see the uptime figures each month?
- Is a failed backup job alerted like a failed health check (Backups)?
Related pages
- Logs for owners
- When the site is down
- Health checks and uptime (for hosts)
- Uptime practice
- Free documentation: this page is free to copy, translate and improve under the GNU FDL 1.3.
Become an Exponential Partner
Partners share their information, provide funding, contribute back and develop the products with us, and that is how Exponential grows. A partner website and dashboard are planned for mid-2027: please become a partner today to speed up our growth rate and land new features faster.