How to use the Uptime Monitor
Enter the URL to watch
Give the address of the page or endpoint you want checked. Public URLs work immediately with no configuration.
Choose what counts as a problem
Alert on the site being unreachable, on an unexpected status code, or on the page content changing from what it is now.
Add where to send alerts
Provide an email address or a webhook. Point the webhook at a chat channel if you would rather the alert arrive where your team already is.
Uptime monitoring is really outside-in testing
Your server can be running perfectly while your site is unreachable. Expired certificates, DNS misconfiguration, CDN rules, firewall changes and load balancer health checks all break the path between a visitor and a working application - and none of them show up in server-side metrics, which is exactly why the application looks healthy while nobody can reach it.
A check from outside your infrastructure tests the same path a customer takes. It is the only monitoring that fails when your customers are failing rather than when your server is.
Watching for content changes, not just outages
A page returning 200 can still be broken. A deploy that empties a product grid, a CMS change that removes a pricing table, a third-party embed that stops rendering - all of them return a perfectly healthy status code while the page is useless.
Content monitoring catches those. It also has uses that have nothing to do with your own site: watching a competitor pricing page, waiting for a supplier stock status to change, or being told when a documentation page you depend on is revised.
Alerts people will still read in six months
The failure mode of monitoring is not missing an outage; it is sending so many alerts that everyone learns to ignore them. A monitor that fires on a single slow response during a routine deploy trains its audience to dismiss it, and the one alert that mattered gets dismissed along with the rest.
Require a couple of consecutive failures before alerting, and send the alert somewhere it will be seen - a chat channel usually beats an email that arrives among forty others. Then, occasionally, break something on purpose to confirm the alert still arrives. Monitoring that has never been tested is a belief, not a control.
Frequently asked questions
- Do I need an account to set up a monitor?
- No. Create a monitor and give it somewhere to send alerts. Monitors you create are remembered in your browser under My stuff.
- Can it alert me when page content changes?
- Yes. As well as availability and status codes, it can watch the content itself, which catches the deploy that returns 200 with an empty page.
- Where do alerts get sent?
- To an email address or a webhook. Pointing the webhook at a chat channel is usually more effective than email, because the alert lands where people already are.
- Will I get alerted for every brief blip?
- Requiring consecutive failures before alerting is the standard defence against noise. An alert channel people have learned to ignore is worse than no alerting at all.