What Building Website Monitoring Taught Me About Silent Failures

Mike — Sat, 13 Jun 2026 20:58:18 +0000

I assumed when building NorthDuty that website monitoring would focus on the obvious failures.

The site is down.

The SSL certificate expired.

DNS is broken.

The server returns 500.

That kind of thing.

Oh and yes those problems are important. If a site is totally down you certainly want to know asap.

But the more I worked on monitoring, the more I came to realize that the most irritating failures are not the loud ones. They are the silent ones.

The website answers back. The status code is acceptable. The home page at least is loading, technically. Doesn't look broken at a simple HTTP sniff.

But for the user, something important is gone.

`200 OK` can lie to you

One of the first lessons was that 200 OK does not mean “the website works.”

It only means the server returned a response.

Simple to say, but easy to lose sight of when you're building monitoring. That's as far as a lot of uptime checks go. They'll make a request, check the status code, maybe look at response time, and consider that healthy.

The problem is that users do not experience status codes.

They experience pages.

A frontend app can return 200 OK and the screen can stay blank because the JavaScript crashed. A dashboard can load the shell but never fetch the data. A pricing page can render, but the CTA button can be invisible because of a CSS change. A checkout flow can fail after the first step, while the homepage looks 100% fine.

From the monitor’s point of view, everything passed.

From the user’s point of view, the product is broken.

That gap is where a lot of silent failures live.

The page can be alive and broken at the same time

This was probably the biggest mental shift for me.

I used to think of websites in black and white, before putting in deeper checks: up or down.

Now I think there is a large middle area.

A site can be “up” but unusable.

A page can load but be empty.

A form can appear but not submit.

A login page can work while the logged-in app is broken.

A marketing site can be perfect while the actual product is failing.

That middle area is dangerous because it does not always trigger alarms.

Monitoring just the homepage, you might overlook the dashboard. Monitoring just the API, you might overlook the frontend. Monitoring just response codes, you might overlook rendering issues. Looking only at logs, you might overlook what the user actually saw.

This is why I started caring more about screenshots, visual diffs, and user flows.

Not because they are fancy features, but because they answer a better question:

What did the user actually get?

Screenshots are surprisingly honest

A screenshot is not perfect, but it is hard to argue with.

If the page is blank, the screenshot shows it.

If the layout exploded, the screenshot shows it.

If a cookie banner covers half the screen, the screenshot shows it.

If the main content never appears, the screenshot shows it.

Adding screenshot-based monitoring changed my perspective on failures. Logs are good, but logs say what the system thought happened. Screenshots say what the user likely saw.

That difference matters.

Of course, visual monitoring has its own problems. Pages are messy. Dates change. Animations move. Fonts load at slightly different times. Ads and third-party widgets do whatever they want. If you alert on every pixel difference, you will create noise fast.

Screenshotting the changes is easy. The hard part is knowing which changes to screenshot.

A visual diff that reports “this page changed by 0.3%” is not inherently useful. A visual diff that highlights “the hero section has disappeared”, “the layout has shifted”, or “the app has rendered an error screen” is quite useful.

That kind of failure is easy to miss with traditional uptime monitoring.

User flows matter more than pages

Yet another useful thing I learned: it's good to monitor a page, but it's better to monitor a flow.

Most visitors aren't just coming to look at a product, they want to do something.

They want to log in.

Create a project.

Submit a form.

Check a report.

Finish checkout.

Invite a teammate.

If one step in that path breaks, the product is broken for that user.

This is particularly true for SaaS products. The homepage can look great while the app itself is not useable. The API can be up while authentication is broken. The dashboard can load while the main action button does nothing.

A single URL check will not catch that.

That's why I think user-flow monitoring is closer to actual reliability. It doesn't ask, "Does this URL respond?" It asks, "Can someone still complete the thing they came here to do?"

That is a much better question.

Silent failures are expensive because users rarely report them

This part is easy to underestimate.

When something breaks, we like to imagine users will tell us.

Sometimes they do. Most of the time, they do not.

They refresh.

They try again.

They assume the product is unreliable.

They leave.

If they're shopping, you may never know you lost them. If they're a customer, they may silently lose faith. If they were ready to buy, they may not.

That's what makes silent failures so aggravating. They do not necessarily cause a big fuss. They just quietly erode confidence.

And because they are quiet, they can stay hidden longer than they should.

What I monitor differently now

Building website monitoring made me less satisfied with basic uptime checks.

I still believe they're required. Status codes, SSL certs, DNS, response time and obvious server failures should be monitored.

But I would not stop there.

Now I care about things like:

Did the page actually render?
Is the screen blank?
Did the frontend throw an error?
Did the visual layout change in an unexpected way?
Are important elements still visible?
Can the main user flow still complete?
Is the mobile version still usable?
Are third-party scripts slowing down or blocking the page?

These checks are closer to what users actually experience.

Because at the end of the day, nobody cares that your server technically responded if the page they needed is broken.

The main lesson

The most valuable lesson that NorthDuty has taught me is that "up" is not equal to "working".

A website can be online and still fail its users.

That's easy to say but it changes the way you approach monitoring. You stop focusing on the infrastructure and you start focusing on the experience. You stop asking if the server responded and you start asking if the product still works from the outside.

Silent failures are hard because they do not announce themselves clearly.

You have to go looking for them.

And once you start looking at sites like that, basic uptime monitoring starts to seem like a first layer.

DEV Community: Mike