Ten monitors is a small number, and that is the point. When one person gets the alert at night, each monitor needs to earn its place. Here is a list that covers most small web apps and client sites, and the reasons behind each slot.
Why 10 monitors is enough to start with
Most small products fail in a handful of places: the front page, the sign-in page, the API, the page where people pay or send an enquiry, and the jobs that run in the background. If you watch those, you will hear about most breakages before a customer does. Ten slots also leave room to add more later without deleting anything.
Start with this list and run it for a month. Then add only what an incident has shown you that you need. Adding monitors because they seem sensible tends to produce a long list of alerts that nobody reads, so let real problems decide what comes next.
The public home page and the sign-in page
Use two HTTP monitors, one for each page. The home page tells you the site is reachable. The sign-in page matters just as much, because a site can serve its marketing pages while users cannot log in at all. A customer who cannot sign in will not think of the site as up, whatever the status of the home page.
Set each alert to fire on failed responses, and keep the alert recipients to people in your organisation who can act on it. A clear alert name helps too. "Sign-in page not responding" tells the person on call where to look straight away.
The API or health endpoint
If your app has an API, watch one endpoint that exercises the real path through the code, not a static file that always returns the same answer. A health endpoint that checks the database is far more useful than one that only returns OK. Keep the response small so the check is quick and cheap to run.
When this monitor goes red, the question is whether the app works for users. Write the alert text so it names the endpoint that failed. That saves the first five minutes of guessing, which is often the longest part of an incident.
The checkout or main form, if you have one
If people pay you or send you enquiries through one page, that page gets its own monitor. These are the pages where a broken deploy costs money on the day it breaks, and they are rarely the first pages anyone checks after a release. Watch the page that loads the form, and if your setup allows it, a page that confirms a submission was received.
If you have no form or checkout, skip this slot and use it later. A brochure site with no forms does not need it.
One heartbeat for the nightly backup
A heartbeat monitor works the other way round from an HTTP check. Your job pings AperioFlow when it finishes, and if the ping does not arrive in the window you set, you get an alert. This catches the failure that has no visible symptom: the backup stopped three weeks ago and nobody noticed because nothing on the site looked wrong.
Place the ping at the end of the script, after the upload has succeeded, not at the start. A ping at the start only proves the script began, and a backup that begins and then fails still looks healthy.
One heartbeat for the busiest cron job
Pick the cron job that would hurt most if it stopped. That might be invoice sending, a data sync with a client's system, or a cleanup task that keeps a database from filling up. Give it a heartbeat in the same way as the backup.
Set the expected interval a little longer than the job's normal run time. A slow night should not wake anyone, but a job that has quietly stopped should. Check the interval after the first few runs, because the right window is usually clear within a week.
Certificate expiry for the main domain
An expired certificate looks like an outage to every visitor, and it is one of the few failures that is completely predictable. Put the main domain's certificate on your list. Before you rely on it, check the monitor types on the pricing page and in the docs, because the available checks may change.
If certificate expiry is not available on your plan, put the renewal date in a calendar with a reminder two weeks ahead. Treat it as a monitor you run by hand, and note in the same place when the certificate was last renewed.
What to leave out until you have a reason
Do not watch every page on the site. Each extra monitor is one more alert someone may ignore, and the alerts that matter get lost among the ones that do not. Leave out pages that rarely change and cannot break a user journey. Leave out internal tools that only you use on a weekday.
After an incident, ask what would have caught it earlier. If the answer is clear, add a monitor for it. If the answer is vague, wait. Ten focused monitors that people trust will do more for you than thirty that everyone has muted.
Start free at https://app.aperioflow.co.uk/#/signup. The free plan has 10 monitors, enough for this list.