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

  • basics

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.
  • 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 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 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 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 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.