Skip to content
Log In
Oh Dear

Up, but still slow

Performance monitoring.

The site is up. The client still feels it. This is a response-time check on the HTTP request Oh Dear already makes, with an alert on a hard millisecond budget or a sudden change against the recent baseline.

Start monitoring See how it works

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

Capterra
4.9 (73) G2
4.7 (33)
Sampled every minute Evaluated every 15 minutes
  • Bitmovin
  • HBO Nordic
  • Obsidian
  • Laravel
  • Fathom Analytics
  • PHP 8
  • Stanford University
  • Takeaway.com
  • IGN
  • VRT NWS
  • spatie

The still-green gap

Uptime is green. Someone is still waiting.

You manage a stack of client sites you did not all build. One of them is still answering 200. Uptime is green. The client, or their customer, is still sitting on a slow page.

The site is not down. It is late. Performance monitoring is the check for that gap. Oh Dear already fetches the URL from its own servers every minute for uptime, and it stores how long each of those requests took. You set a budget in milliseconds and a sudden-change percentage, so a slowdown does not go unnoticed while uptime stays green.

You are not waiting on a visitor to complain, and you are not waiting on yesterday's Lighthouse run. You are looking at the request Oh Dear just made.

This is one check inside website health monitoring. It does not replace website uptime monitoring, and it does not score the page the way Lighthouse SEO monitoring does. It asks a narrower question: is this URL still fast enough, and did that change?

You already get the 2am down alert. This is the slower failure, where the site works and the ticket still arrives.

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

Casey Sprague, CTO at thera-LINK

Up and slow is not the same as down. Uptime does not separate them.

Five phases, one number

See which part of the request got slower.

A total response time tells you something is wrong. The breakdown tells you where to look, because a slow TLS handshake and a slow database query are not the same ticket.

Getting there

DNS lookup How long resolving the hostname took before anything else could start.
TCP connection How long the connection took to establish, which is where the network shows up.
TLS handshake How long the certificate exchange took on an HTTPS request.

The response

Server processing Time to first byte: how long your application spent building the response.
Content download How long the body took to arrive once the server started sending it.
Status code What the server answered, stored next to the timings for the same request.

Over time

A year of metrics Response-time samples are kept for a year, so you can still see the trend long after an incident.
Ranges to compare From the last hour out to the last year, or a custom window you pick.
In the client report A performance section can be included in the monthly report you send on.

One narrow question

What this check sees, and what it does not.

Performance monitoring measures how long an HTTP request took. The neighbouring checks answer genuinely different questions, and this one is not a synthetic checkout.

This check

Response time

How long the HTTP request took, and which of its five phases moved.

A different check

Ping

Ping monitoring is ICMP: did the host answer at all.

What it checks

  • Response time of a website or an API, measured from Oh Dear's own checker servers.
  • A hard threshold in milliseconds: cross it and the check fails.
  • A sudden change against the baseline of the preceding two hours.
  • DNS, TCP, TLS, server processing and content download, stored per sample.
  • A year of response-time history, from a last-hour view out to a last-year one.

What it does not

This is not a checkout, a login flow, or a scripted journey. It times the request you pointed it at.

Operational ownership

Send the slowdown to the person who owns the fix.

A slow checkout on client A is not the same person's problem as a slow API on client B. Oh Dear routes each site's performance alerts to the channels that team already uses.

Slack receives the alert; it does not rerun the check. The next evaluation is 15 minutes away, and the monthly client report can carry the performance section for the people who never open a dashboard.

Slack
Email
Webhook
Explore notifications and routing

Agency first

Who needs this check most.

Clients do not distinguish "up" from "feels slow." This check keeps that wait visible across a whole roster of sites.

Agencies running sites they did not build.

You are responsible for sites on hosts you do not control. Uptime can stay green across the whole roster while one customer waits eight seconds for a product page.

Web agencies use this so that wait becomes Oh Dear's alert rather than the client's email.

SaaS teams whose URL still returns 200.

The product URL or the API answers every request, and response time is climbing anyway. Websites and APIs share this check, so the same budget and the same alerting cover both.

It is not a one-off speed test you run when someone remembers. It runs on the sites you are already responsible for.

No feature tiers

Every check.
Every plan.

Performance monitoring is included on every plan. You pay for the number of sites you monitor, not per check, so you are not stacking a second speed vendor on top of your monitoring.

Start with everything on.

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

  • Performance monitoring included
  • Every feature on every plan
  • Pay for the number of sites
  • No credit card required
Start a free trial

10-day free trial. No credit card.

For the technically curious

How the performance check actually works.

Oh Dear times the HTTP request it already makes for uptime, stores the phases, and evaluates them on a schedule. Nobody has to be on the site.

  • Sampling. Timings come from the uptime request, so a sample lands every minute for an HTTP monitor. Checks run from Oh Dear's own checker servers, and you pick which location is the primary one for a site.
  • Alert cadence. Those samples are evaluated for a slowdown every 15 minutes. Do not expect a one-minute performance alert: uptime is checked every minute, this check is not.
  • Hard threshold. A budget in milliseconds, between 50 and 10,000. New monitors start at 3,500 ms. API field: performance_check_settings.threshold_in_ms.
  • Sudden change. Oh Dear compares the average of the past 15 minutes against a baseline built from the two hours before that window. It needs enough samples on both sides, and the change has to fall outside the baseline's normal spread, so an ordinary busy minute does not page anyone. API field: change_percentage, in the same settings group, starting at 50%.
  • First alert. failed_notification_threshold sets how many consecutive slow evaluations pass before the first alert. Leave it at 0 or 1 to hear about the first one. It applies to the hard threshold; the sudden-change alert fires on its own terms.
  • Timing breakdown. Each sample stores the DNS lookup, TCP connection, TLS handshake, remote server processing (time to first byte) and content download, alongside the status code.
  • History. Response-time metrics are kept for a year. The viewer opens on the last hour and ranges out to the last year, or a window you set. Individual check-run detail pages are pruned after ten days; the metrics behind the graphs are not.
  • Websites and APIs. Both are HTTP monitors, so both get these timings. If an endpoint needs a specific method, payload or response assertion, configure API monitoring as well.

Want all the technical details?

Uptime and performance monitoring How often checks are performed

Before the first check

Questions about performance monitoring.

What Oh Dear measures, how often it evaluates it, and where this response-time check ends.

What is performance monitoring?

Performance monitoring is a synthetic HTTP response-time check run from Oh Dear's own servers. It is not real-user monitoring, not Lighthouse, and not uptime. It measures how long the request took and alerts on a millisecond budget or on a sudden change against the recent baseline.

Why do you need performance monitoring?

Because performance problems do not announce themselves. A slow query, a third-party script timing out, a cache that quietly stopped working: none of them triggers an uptime alert, they just slow the site down until someone complains. Watching response time is how you find that before a visitor does.

What does Oh Dear measure when a page is slow?

Every sample stores the DNS lookup, the TCP connection, the TLS handshake, the time your server spent building the response, and the content download. When a page slows down, you can see which of those five phases moved.

How often does Oh Dear check performance?

Response times are sampled with every uptime check, so once a minute. Oh Dear evaluates those samples for a slowdown every 15 minutes, which is the cadence that produces an alert.

Is this real-user monitoring (RUM)?

No, and we would rather be straight about it. Oh Dear runs synthetic checks from its own servers, so monitoring keeps working even when nobody is visiting. What you do not get is what a specific visitor on a specific device experienced.

Can I set a performance budget or response-time threshold?

Yes. Set a hard threshold in milliseconds, anywhere from 50 to 10,000; new monitors start at 3,500 ms. Pair it with a sudden-change percentage, which starts at 50%, so a sudden jump compared to the recent baseline is reported before it reaches the hard limit.

How does the sudden-change alert work?

Oh Dear compares the average response time of the past 15 minutes against a baseline drawn from the two hours before that window. It also needs enough samples on both sides and a change that sits outside the baseline's normal spread, so an ordinary busy minute does not alert anyone. A drop counts too: a cache serving empty pages looks faster and is still wrong.

Will I know the moment my site gets slow?

No. You hear at the next 15-minute evaluation, once your threshold or sudden-change rule is met. The number of consecutive slow evaluations before the first alert is failed_notification_threshold; leave it at 0 or 1 to be told about the first one.

How long is performance history kept?

Response-time metrics are kept for a year, which is enough to show a slow Friday deploy and the trend across seasons. The individual check-run detail pages are pruned sooner, after ten days.

How is this different from website uptime monitoring?

Website uptime monitoring asks whether a public URL is reachable, every minute, and by default treats the site as down if it does not respond within 5 seconds. That timeout is configurable from 1 to 10 seconds. Performance monitoring asks a different question of the same request: how long did it take, and did that change?

How is this different from Lighthouse SEO monitoring?

Lighthouse SEO monitoring runs Google Lighthouse and reports performance, accessibility, best-practice and SEO scores from a real browser. Performance monitoring is HTTP response time, sampled far more often and alerted on directly.

Can I monitor API response time?

Yes. Websites and APIs run through the same HTTP check, so the same timings and the same alerting apply. Extra payloads, methods and response assertions for individual endpoints belong with API monitoring.

Does this test a checkout or login?

No. This check is not a synthetic checkout and it does not script a journey. It times the HTTP request you pointed it at.

Can agencies monitor client site speed?

Yes. Point a monitor at each client URL, set the millisecond budget and the sudden-change percentage, and route alerts to whoever owns that site. Client reports can include a performance section, so the client sees the trend without logging in. More at Oh Dear for web agencies.

Is performance monitoring included in every plan?

Yes. Every feature is on every plan. You pay for the number of sites you monitor, not for turning this check on, so you are not stacking a second speed vendor on top of your monitoring.

See all other FAQ items
Technical detail Read uptime and performance monitoring A different check Lighthouse SEO monitoring

Get started

Start monitoring the slowness you're already responsible for.

The site can stay up and the client can still feel the wait. Put a budget on the URL before that wait becomes a message to you. No credit card.

Capterra
4.9 (73) G2
4.7 (33)
Start monitoring