Uptime monitor
Watch an API, a page, a port, a DNS record or a certificate, and hear about it by email when something breaks. One of three tools here that needs an account, because it has to keep running while you are asleep. The rest of the site runs in your browser and sends nothing anywhere.
Watching
Sign in to see what you are watching.
What it can watch
- A web page
- The status code, and optionally a word that must or must not be on the page. That second part catches the failure a status check cannot see: a page returning 200 that says the database is unreachable.
- An API endpoint
- A real request, not just a fetch: the method, headers, a body, and what the answer has to say. It checks a value at a path in the JSON rather than searching the text for a word, which is the difference between checking the answer and checking that some bytes went past. An API returning 200 with a status of degraded is up by every other measure here. It can also call a correct but slow answer down, because an API that takes nine seconds is useless to whatever is calling it.
- A TCP port
- Postgres, Redis, SSH, SMTP, a game server. It connects and hangs up, which is the honest check: if the handshake completes, something is listening.
- A DNS record
- A, AAAA, CNAME, MX, TXT or NS, optionally matching an expected value. This is what catches an expired domain or a botched record change, which a web check reports only as an unexplained outage.
- A TLS certificate
- How many days it has left, with a warning at three weeks, two weeks, one week, three days and one day. The only outage that is entirely preventable.
Questions
- Will it wake me up for nothing?
- It should not. Nothing is called down on a single failed request, because one failed request is a dropped packet somewhere on the internet rather than an outage. Two consecutive failures is the default and you can set it up to five. There is also a quiet window, thirty minutes by default, so something that flaps up and down cannot send forty emails an hour and get the whole address filtered.
- What does the alert actually say?
- What was observed, not what we concluded. The subject line carries the whole fact, because that is what you will read on a lock screen: which thing, and what happened to it. The body says what was watched, what the failure was, how many checks confirmed it and how far apart they were. A connection refused, a 503, an expired certificate and a timeout are four different afternoons.
- Do I get told when it comes back?
- Yes, with how long it was down. An outage nobody is told has ended is an outage somebody keeps worrying about. Recovery is reported on the first successful check rather than waiting for confirmations, because a false all-clear costs nothing and an extra half hour of worry does.
- How accurate is the uptime percentage?
- It is a percentage of the checks that ran, and it is only as good as the interval. A fifteen minute check cannot see a ten minute outage, so the interval is printed next to every figure. Any product that shows you 99.99% without telling you how often it looked is overstating what it knows.
- Can I have a public status page?
- Yes, as many as you watch things, each at an address you choose, and all of them off by default. Separate pages matter as soon as you run two things that are not the same product: customers of one have no business reading about the other one's outage. You pick which monitors appear on each, a monitor can be on more than one, and a page never publishes the address being watched: not the URL, not the hostname of your database, not the port it answers on. The name you give a monitor is public, and it starts out as the host, so rename anything you would not put on a billboard. Each page is one file with no scripts, no fonts and no images, because a status page that depends on a CDN goes down with the CDN.
- Where do the API credentials go?
- Into the headers on an API monitor, and they are the first thing here that belongs to you rather than to us. They cannot be hashed the way a password is, because the next check has to send them again, so they are encrypted before they are stored and the key is not in the database. They are never returned, not even to you: the names come back so a form can say which are set, and changing one means sending it again. They are never logged and never reach a status page.
- Is there a ping check?
- No, and be suspicious of anything that offers one from a serverless host. ICMP needs a raw socket and a raw socket needs root, so what is usually labelled ping is a TCP connect wearing a different name. A port check does the same job and says what it is.
Also here: the SEO audit and the article writer. What is stored is in the privacy note.