Skip to main content

Synthetic monitoring vs uptime monitoring: why 'all green' can still mean broken

· 4 min read
The VeriWasp Team
The VeriWasp Team
Automated testing for indie SaaS

Your status page is green. Your uptime monitor says 100%. And your signup form has been throwing a JavaScript error for six hours. Both things are true at once, and that is the whole problem with relying on uptime monitoring alone: it checks that your server is answering the phone, not that anything useful happens when it does. The dashboard that makes you feel safe can be green through an outage that is quietly costing you every new customer.

What uptime monitoring actually checks​

Uptime monitoring, the Pingdoms and UptimeRobots of the world, periodically requests a URL and checks that it comes back with a 200 and maybe some expected text. That is genuinely useful. It catches the server being down, the SSL cert expiring, the domain lapsing, the whole app returning 500s. If your box falls over, you want to know, and this tells you.

But look at what it is really measuring: your homepage returns a successful response. That is a low bar. Every one of these can be true while uptime is a perfect 100%:

  • The homepage loads, but the signup form's JavaScript throws and the button does nothing.
  • The API is up, but a background request on the dashboard 404s and the app renders empty.
  • The checkout page returns 200, but the payment iframe never loads.
  • Login returns 200, but the session does not persist and users loop back to the login screen.

Uptime monitoring sees a 200 in every case and reports all clear. The flow a customer needs is broken, and your monitoring has no idea, because it never tried to use it.

What synthetic monitoring checks​

Synthetic monitoring closes that gap by doing what a user does. Instead of pinging a URL, it drives the actual flow in a real browser on a schedule: it loads the page, fills the form, clicks the button, and checks that the right thing happens. It is "synthetic" because it is a scripted user rather than a real one, run continuously so you catch a broken flow in minutes rather than in a drop in your conversion numbers days later.

The difference is the difference between "the restaurant's lights are on" and "someone walked in, ordered, and got fed." One is necessary. The other is what you actually care about.

You need both, for different jobs​

This is not an argument to drop uptime monitoring. The two answer different questions:

  • Uptime monitoring answers "is the server up?" It is cheap, fast, and the right tool for catching hard-down outages and infrastructure failures.
  • Synthetic monitoring answers "can a customer actually complete the flows that matter?" It is the only thing that catches functional breakage, the silent kind that leaves uptime green.

Run uptime checks for infrastructure and synthetic checks for your critical flows: signup, login, checkout, the core action your product exists to do. Together they cover both "the lights are on" and "the thing works."

How VeriWasp fits​

VeriWasp is synthetic monitoring for your real user flows. You describe a flow once, and it runs in a real browser on a schedule, hourly, daily, or weekly, driving the actual signup, login, or checkout the way a customer would and confirming the expected result appears. When a flow breaks, you get a report tied to the exact step, with the console errors, network traffic, and a video, so you are not just told "something is wrong," you are shown what and where.

You can put your critical flows under continuous checks with a few free runs, no card required. Uptime tells you the server is answering. Synthetic monitoring tells you your business still works.