Skip to content
Oh Dear

While you are not looking

Website uptime monitoring.

See the problem before someone reports it. Oh Dear requests your site every minute from its own servers around the world, confirms a failure from a second location before alerting anyone, and keeps the evidence of what happened.

10-day free trial · No credit card required · Every feature included

Every minute Verified from a second location
  • Bitmovin
  • HBO Nordic
  • Obsidian
  • Laravel
  • Fathom Analytics
  • PHP 8
  • Stanford University
  • Takeaway.com
  • IGN
  • VRT NWS
  • spatie

The one-shot checker problem

See the problem before someone reports it.

You cannot refresh every site, from every place, at every hour. A checker you run by hand only ever answers for the moment you ran it.

Most outages are found by the wrong person. A customer emails, a client rings, someone posts in a channel you were not watching. By then the question is no longer whether the site was down; it is how long it was down and why nobody noticed.

A scheduled check from outside your network answers that continuously and keeps the record. When a site fails, the run holds the response it gave and the location that saw it, so the conversation starts from evidence rather than from someone's memory of a screenshot.

It also catches the outage that is invisible from your desk: the site that is fine from your office and unreachable from the continent your customers are actually on.

Casey Sprague
Oh Dear detected an issue that our other uptime monitor did not!

Casey Sprague, CTO at thera-LINK

Two locations have to agree before you are woken up.

A status code is not proof

The green status code problem.

Plenty of broken sites still answer with a normal status code. A check that only looks at that code will call them healthy.

The response itself

Status code Anything outside 2xx counts as down by default, and you can widen that per site.
Redirects Followed to the end of the chain, and the final response is the one that decides the outcome.
Timeout A response that has not arrived in time is down. Five seconds by default, settable from one to ten.

What the page contains

Required string Text that has to appear in the response. A 200 without it is treated as down.
Forbidden string The inverse. If your error template says something specific, fail on seeing it.
Response assertions Assert on values inside a JSON response, for when a status code alone is not precise enough.

How it is requested

Method and payload GET, POST, PUT or PATCH with a body of your own, so a form or an API endpoint can be monitored properly.
Custom headers Send the headers the endpoint needs, including whatever it uses for authentication.
Accepted codes Tell the check which status codes are legitimate for this particular URL.

Two locations, then an alert

No alert until a second location agrees.

One checker with a brief network problem is not the same thing as your site being down, and a monitoring tool that cannot tell those apart trains you to ignore it.

Both locations fail

Downtime

The incident opens, the alert goes out, and the time counts against your uptime percentage.

First fails, second succeeds

Warning

Recorded so you can see it happened, but it is not downtime and it does not move your percentage.

Still failing

Checked every minute

A monitor that is currently down is re-checked every minute whatever its normal frequency, so the recovery is noticed as fast as the failure.

Operational ownership

Send the outage to the person who owns the fix.

One client's site going down is not everyone's problem. Each site routes to its own people on the channels that team already uses, so the 3am alert reaches whoever can actually act on it.

The same checks can feed a status page that updates itself, on your own domain, so customers stop asking whether you know.

Slack
Email
Webhook
Explore notifications and routing

No feature tiers

Every check.
Every plan.

Uptime monitoring is included on every plan, along with the rest of the website-health toolkit. You pay for the number of sites you monitor, not for which checks you switch on.

Start with everything on.

Uptime, performance, certificates, DNS, broken pages and the rest sit on the same site and the same bill.


  • Uptime monitoring on every plan
  • Every monitoring feature included
  • Status page custom domain included
  • No credit card required
Start a free trial

10-day free trial. No credit card.

For the technically curious

How the uptime check actually works.

The mechanics behind every alert, and the thresholds you can move yourself.

  • Cadence. Every minute by default, settable per site from one to sixty minutes. A monitor that is currently failing is dispatched every minute regardless of that setting.
  • Locations. 33 checker servers across 16 cities on six continents. You choose the primary location per site; the verification check deliberately runs from a different city and a different provider.
  • Verification. A failure at the primary location is re-checked from the alternative before anything is raised. Both have to report down for an incident. Primary down plus secondary up is a warning, which is recorded but is not downtime and does not affect your uptime percentage.
  • What counts as down. By default any response outside 2xx, which makes a 204 a success and a 503 an outage. Redirects are followed, up to five by default, and the final response is judged.
  • Timeout. Five seconds by default, settable from one to ten. A response that has not arrived by then is a failure, which is why an extremely slow site eventually reads as a down site.
  • Before you are alerted. Two minutes of downtime by default, settable from one to twenty. This is a duration, not a count of failed checks: raising it lets a short blip pass without an alert, without changing the check interval.
  • Content checks. A required string, a forbidden string, and JSON response assertions. Any of them failing marks the monitor down even when the status code is fine.
  • The request. GET, POST, PUT or PATCH, with form or raw JSON payloads and your own request headers, so an API endpoint or a form submission can be monitored the way it is really used.
  • History. Uptime percentage over the past 7 days and the past 12 months, plus an all-time figure once a monitor is older than a year. Each incident keeps its start, end and duration, and each run keeps the response code and the location that saw it.

Want all the technical details?

Before the first check

Questions about uptime monitoring.

What counts as down, where the checks come from, and what you can tune.

What is uptime monitoring?

It is a request to your public URL, repeated on a schedule from outside your network, that records whether the site answered and how. When it stops answering the way you said it should, the people responsible get told.

What are the benefits of uptime monitoring?

You find out before your customers do, and you can prove what happened afterwards. Without it, the first report of an outage comes from whoever was inconvenienced by it, and nobody can say how long it really lasted.

How do I track site uptime?

Point a monitor at the public URL and let it run. Oh Dear records every check, turns the failures into incidents with a start, an end and a duration, and gives you the percentage over the past 7 days and the past 12 months.

How often does Oh Dear check a site?

Every minute by default, and settable per site from one to sixty minutes. A monitor that is currently failing is re-checked every minute regardless, so recovery is noticed as quickly as the failure was.

Where do the checks come from?

From Oh Dear's own servers: 33 of them across 16 cities on six continents. You pick the primary location for each site, which matters more than it sounds when your audience is in one part of the world and your server is in another.

What happens when a check fails?

It gets checked again from a different city, on a different provider, before anyone is woken up. Both locations have to agree the site is down. If the first location fails and the second succeeds, the run is recorded as a warning rather than downtime, and it does not touch your uptime percentage.

What counts as down?

By default, anything that is not a 2xx response, which is why a 500 or a 503 registers as downtime. Redirects are followed and the response at the end of the chain is the one that counts. You can widen the accepted codes per site if your setup legitimately answers with something else.

What if the site is slow rather than broken?

A response that has not arrived within the timeout counts as down. That timeout is 5 seconds by default and you can set it anywhere from 1 to 10 seconds. If what you actually want is to watch response time trend rather than fail on a hard limit, that is performance monitoring.

How long before I get an alert?

Two minutes of downtime by default, and you can set that anywhere from one to twenty minutes. It is a duration rather than a count of failed checks, so raising it lets a short blip pass without an alert, without changing how often the site is checked.

Can Oh Dear check the page actually rendered?

Yes, in two ways. Give it a string that must appear in the response and a 200 without that string is treated as down, which catches the deploy that returns a blank but technically successful page. You can also assert on values inside a JSON response, which is the more precise version of the same idea.

Can I monitor something other than a plain GET?

Yes. GET, POST, PUT and PATCH are supported, with your own payload and custom request headers, so you can monitor a form submission, a search, or an API endpoint that needs a real body rather than just a homepage.

Can I put the results on a status page?

Yes, and it updates from the same checks rather than needing anyone to remember to post an update. A custom domain is included on every plan, so it can live on your own hostname. Details on status pages.

How far back does the uptime history go?

You get a percentage over the past 7 days and the past 12 months, and an all-time figure once a monitor has been running longer than a year. Individual incidents keep their start, end and duration, so you can answer what happened without asking the customer to reproduce it.

Is uptime monitoring included in every plan?

Yes. Every feature is on every plan. You pay for the number of sites you monitor, not for which checks you switch on.

See all other FAQ items

Get started

Start monitoring the sites you're responsible for.

Add a site in under a minute. Every feature on. No credit card.