How to Set Up Website Uptime Monitoring

Your customers shouldn't be the ones who tell you the site is down. A monitor checks for you around the clock, from outside your infrastructure, the same way a visitor would reach it.

How a monitor works

Every check is one HTTP request to your URL. A check passes or fails. A single failure doesn't page anyone: the monitor waits until the last few checks in a row have failed (the failure threshold), then opens an incident and sends an alert titled Down: <monitor name> to the monitor's team. The first check that passes again closes the incident and resolves the alert.

The alert is an ordinary Sigtake alert, so it follows the team's routing: every member sees it in the app, and the team's channels in the monitor's project deliver it to Slack, Microsoft Teams or email. If that part isn't set up yet, start with setting up alert notifications for a team.

What counts as down

A check fails when any of these happens:

A slow response is not down: a site that answers in eight seconds is still up. Each check's response time is recorded and charted on the monitor's page, so you can spot a site getting slower before it starts timing out.

Set it up

1. Check the team can receive alerts

   A monitor sends its alerts to one team. Make sure that team is added to the project you're working in and has at least one channel attached there, or the alert will only show up in the app.

   Monitors belong to a project, like alerts do. Pick the right one in the project switcher before you start: a monitor for your production site goes in Production.

2. Add the monitor

   Open Monitors in the sidebar and use Add Monitor. Give it a name your team will recognize in an alert, paste the full URL including https://, and pick the team.

   The name becomes the alert title, so Checkout API reads better at 3 a.m. than monitor-2. Point the URL at a page that proves the app works, not just that the server is on: a /health endpoint that touches the database beats a static homepage served from a CDN. Operators and admins can create monitors.

3. Choose how often to check and how sure to be

   Set Check Interval and Failure Threshold together. For a production site, 1 minute and 2 consecutive failures catches an outage in about two minutes while ignoring a single dropped request.

   The time to detect an outage is roughly the interval multiplied by the threshold:

   Interval × threshold	Alert after about	Good for
   1 min × 2	2 minutes	Production sites and APIs customers depend on
   5 min × 2	10 minutes	Staging, internal tools, marketing pages
   1 min × 1	1 minute	Testing, or a target that never blips
   15 min × 3	45 minutes	Things nobody needs to wake up for

   A threshold of 1 alerts on every network hiccup between us and your server. Most teams that start there move to 2 within a week.

4. Say what healthy looks like

   Leave Expected Status at 200 unless the URL answers with something else when it's fine. Keep SSL Check on for any https:// URL. Then use Create Monitor.

   The expected status must match exactly. If your health endpoint answers 204 No Content, set 204: a 200 would count as a failure. Leave Response Limit empty for now, since a slow response doesn't take the monitor down. The Advanced settings section, for request methods, headers, tokens and checks on the response body, isn't needed for a public page. For an endpoint behind a token, or to check what the response says, see monitoring an authenticated API health endpoint.

5. Test it with a monitor built to fail

   Create a second monitor against a page that doesn't exist on your site, with a 1 minute interval and 1 failure as the threshold. Within about two minutes a Down alert should reach your team's channels. Then change the test monitor's URL to your real page: the next check passes and the alert resolves on its own. Delete the test monitor afterwards.

   For example, https://yoursite.com/sigtake-monitor-test should answer 404, which isn't the expected 200. The alert reads Down: <test monitor name> with the reason Expected status 200, got 404. If it arrives everywhere you expect, your real monitor's alerts will too, and the recovery proves the other half: the team hears when it's over. Change the URL before deleting, since deleting a monitor leaves its open alert behind.

After it's running

• Recovery is automatic. When a check passes again, the incident closes, the alert resolves, the team is told it recovered, and a Slack card turns green. Nobody has to resolve it by hand.
• The monitor's page is your status history: uptime for the last 24 hours, 7 days and 30 days, a 90-day uptime bar, response times, past incidents and every recent check with its status code.
• The certificate's days left are shown there too, turning amber under 30 days and red under 7. An expiring certificate doesn't alert until it actually expires; then the check fails as invalid. Renew before the colour changes.
• Pause during planned maintenance. A paused monitor isn't checked, so a deploy window doesn't page anyone. Resume it when you're done.

If something looks wrong