What a basic uptime monitor does
A website uptime monitor requests a URL on a schedule. Each time it asks, it looks at the answer. If the answer is what you expected, it records a pass. If the answer is wrong, or there is no answer at all, it records a failure and can send an alert.
That is the whole job. It does not tell you why the site is down. It tells you that something stopped giving the right answer, and when. The rest of the work is up to you: looking at the page, reading the logs, and fixing the problem.
For a small site, a monitor that checks one URL on a schedule is enough to start. The goal on day one is not to watch everything. It is to know, quickly and reliably, when the thing your customers use has stopped working.
Choosing what to watch first
Start with three pages.
The home page. This is the first thing a visitor sees. If it fails, almost everything else probably does too. It is also the page most likely to show a server error after a deploy.
The sign-in page. If people cannot log in, they cannot use the product, even if the home page loads. Sign-in often depends on other services, such as a session store or an identity provider, so it can break when the home page still works.
One page that reads from your database. Pick a page that loads real data, such as a product list, a client dashboard or a set of articles. A static page can keep returning a response while the database behind it is down. A page that reads from the database will fail when the database fails.
These three give you a small, useful picture. If you run an agency or a product with more pages, add the ones that take payments, accept forms or carry the most traffic. Do not add pages just because they exist. Every monitor is one more alert that someone may have to act on.
Setting the check interval and deciding how many failed checks count as an incident
The check interval is how often the monitor asks. A shorter interval finds problems sooner. A longer one sends fewer requests to your server and keeps the alert volume lower. For most small sites, a few minutes is a sensible middle ground. Pick the interval your monitor settings offer that fits how quickly you need to know.
The second decision matters more than the first. A single failed check is not always an incident. A server can time out once during a busy moment, a deploy can restart a process, or a network path can drop a single request. If every single failure sends an alert, people learn to ignore alerts.
So decide on a number of failed checks in a row before something counts as an incident. Two or three consecutive failures is a common starting point. It means a short blip does not wake anyone, but a real outage is still reported within a few minutes. Write the number down, so you and your team agree on what an incident means.
You can change these settings later. On day one, choose a sensible interval and a failure count, then watch the first week of results. If you get alerts for brief blips, raise the count. If a real problem took too long to reach you, lower it.
Who should get the alert
Name one person first. An alert that goes to a group can end up with nobody acting on it, because everyone assumes someone else has it. Pick the person who is most likely to be near a laptop when something breaks. For a solo developer, that is you. For a freelancer, it is the person who looks after the client's site. For a small team, it is whoever is on call that week.
Once that person is getting alerts reliably, add the rest of the team. Adding people too early spreads responsibility thin. Starting with one person shows you whether the alert is useful before it becomes a team habit.
Write the name next to each monitor in your notes. When an alert arrives at 2am, you should not have to work out who owns the site.
Where alert emails go
Alert emails go only to people in your organisation. You choose who is in the organisation, and only those people receive the alerts for its monitors. Check the list when someone joins or leaves, and remove people who no longer need to know.
This matters most for agencies. If you run sites for several clients, keep the monitors for each client's site in the right place, and make sure the people who get the alerts are the people responsible for that work. An alert about a client's checkout page should not go to someone who is not working on that project.
Setting up the same checks on the free plan
The free plan includes 10 monitors. That is enough to cover a small site and its main pages.
Here is a sensible set for one site:
- The home page.
- The sign-in page.
- A page that reads from the database.
- The checkout or contact form, if you have one.
- The API health endpoint, if your app has one.
- The main client-facing product or dashboard page.
- Any other public page that earns money or gets the most traffic.
- A second site, if you run one.
- Spare capacity for a new page you may add later.
- A heartbeat monitor for a cron job or backup, if you have one.
A heartbeat monitor works differently from a URL check. Your scheduled job or backup script sends a signal each time it finishes. If the signal does not arrive on time, the monitor raises an alert. This catches the failure that a URL check misses: the page still loads, but the nightly backup stopped running a week ago.
For each monitor, set the same four things: the URL, the response you expect, the interval, and the alert recipient. Once the first set is working, you can copy the pattern for each new page.
A short checklist to copy
Use this for each monitor:
- URL: the full address of the page, including https.
- Expected status: the response you expect when the page is healthy, usually a normal success response.
- Interval: how often the monitor checks, chosen from the options in your settings.
- Failure count: how many failed checks in a row count as an incident. Start with two or three.
- Alert recipient: one named person in your organisation.
Write these down in a shared note or a document your team can see. When a monitor changes, update the note.
If you do not have an account yet, you can start free at https://app.aperioflow.co.uk/#/signup. Set up your three core pages first, leave the rest of the 10 monitors for later, and review the alerts after a week.