# How to set up uptime monitoring (in about ten minutes)

> What to monitor, which check types to use, how often to check, and who should be woken up - four decisions, then the setup itself takes minutes on any monitor.

Published: 2026-08-01 | Updated: 2026-08-17 | Canonical: https://yoping.me/guides/how-to-set-up-uptime-monitoring

Setting up uptime monitoring is four decisions and then some typing. The
decisions matter more than the tool: get them right and any decent
monitor will serve you well; get them wrong and the best tool on earth
will either miss your outages or wake you for nothing. This guide walks
the decisions in order and ends with the typing. It applies wherever you
set up monitoring; the last section shows the flow on YoPingMe.

## What should you actually monitor?

Monitor what a user touching your product touches, not what your
architecture diagram says. Start with three URLs:

1. **The page users land on** - your homepage or app entry point. If
   this is down, everything is down as far as the world knows.
2. **The thing users pay you for** - the app dashboard, the checkout,
   the API your customers call. A marketing page can be up while the
   product is on fire.
3. **The dependency that fails quietly** - the API health endpoint, the
   login provider callback, the domain your webhooks come from.

Skip internal services a user never reaches directly; if their failure
matters, it shows up in one of the three above. With ten monitor slots
you can cover two or three sites this way and still have room.

## Which check type does each URL need?

- **HTTP** is the default: request the URL, expect a 2xx. Right for
  pages and health endpoints.
- **Keyword** catches the failure HTTP misses: the server answers 200
  but the page is an error screen or an empty shell. Check for a word
  that only appears when the page really rendered - a product name in
  the footer beats "welcome".
- **SSL** watches certificate expiry. An expired certificate takes your
  site down as thoroughly as a dead server, and it is the most
  preventable outage there is - see the
  [expired-certificate guide](/guides/ssl-certificate-expired).
- **Ping** answers "is the host reachable at all" - useful for machines
  that are not web servers.
- **TCP** checks a specific port: a database, a mail server, anything
  that listens but does not speak HTTP.

A practical set for one product: HTTP on the homepage, keyword on the
app's signed-out screen, SSL on both domains, TCP on anything a customer
connects to directly.

## How often should checks run?

Five minutes is the standard free-tier interval, and it is enough for
most sites: your worst case is learning about an outage four minutes
after it starts. Paying for 30-second or 1-minute checks buys faster
detection, which matters when every minute has a price tag - an
e-commerce checkout, an API with contractual SLAs. If a one-minute
detection gap costs you real money, you already know it; if you have to
wonder, 5 minutes is fine. The
[downtime cost calculator](/tools/downtime-cost-calculator) turns that
hunch into a number.

## Who should be alerted, and how?

The goal is that an alert always means "act now". Two rules get you
there:

- **Route by urgency.** Email is for things you will read in the
  morning. Slack (or a webhook into whatever you use) is for things the
  on-duty person should see within minutes. If a check would never make
  anyone act, delete it - it is noise in training.
- **Distrust single-location checks.** A monitor that checks from one
  place will eventually page you because a network path between its
  data center and your server hiccuped, while every actual user is
  fine. Before trusting any alert setup, know how your monitor decides
  a site is down - one failed request from one region is not an outage.
  The [up for me but down for others](/guides/up-for-me-but-down-for-others)
  guide shows how often location is the whole story.

Then test the pipeline once: point a temporary monitor at a URL that
does not exist and watch the alert arrive where you expected it. An
alert channel you have never seen fire is a hope, not a setup.

## Setting it up on YoPingMe

The four decisions above are the work. On [YoPingMe](https://app.yoping.me/signup)
the typing part looks like this:

1. Sign up at app.yoping.me/signup - no card. The first-run wizard runs a live
   first check from your check regions while you are still signing up,
   so you see real results before you have picked a password.
2. Add monitors for the URLs you chose - up to 10 on the free plan,
   using any of the five check types, each checked every 5 minutes from
   two regions. Pick those two per monitor out of five probe locations -
   Frankfurt, Virginia, Singapore, Oregon, and London: a site that is
   geo-blocked in one country stops raising false alarms once you drop
   that region.
3. If you run a WAF, a CDN, or bot protection, [allowlist the probe](/probe/allowlist)
   now rather than after it pages you at 3am for a challenge page.
4. Point alerts at email, a webhook, or Slack. Nothing pages you until
   both regions agree the site is down, which is the single-location
   false-positive problem handled by design.
5. Run the not-a-real-URL test, watch the alert arrive, and go back to
   work.

That is the whole setup. The monitor's job from here is to stay quiet
until it matters.