Your website is up. Your JavaScript is not.
A site can return 200 OK while broken JavaScript leaves users with missing buttons, empty pages or dead interactions.
By Ștefan P
In this article · 6 sections
A website can be perfectly healthy from the server’s point of view and completely broken in the browser.
The HTML loads. TLS is valid. The server responds in 180 ms. Your uptime monitor stays green.
Then a JavaScript bundle fails.
GET / → 200 OK
GET /app.js → 200 OK
GET /checkout.js → 404Nothing about the first request tells you whether the browser successfully built the page users actually see.
That distinction matters more every year.
Modern websites rely on JavaScript for navigation, forms, checkout interfaces, dashboards, authentication UI, modals and almost every interactive part of the page.
If a critical bundle disappears, the server may remain completely healthy.
The product does not.
What a user sees
A failed JavaScript dependency rarely presents itself as a neat error page.
Instead, you get things like:
- a button that does nothing;
- an empty content area;
- a loading spinner that never finishes;
- navigation that stops opening;
- a component that never renders;
- a form whose submit handler never attaches.
The page can still look mostly normal.
That makes these failures particularly easy to miss.
Why an HTTP check cannot see this
An HTTP monitor asks the server a useful but limited question:
Can I request this resource?
A browser has to answer many more:
- Did the scripts load?
- Did they execute?
- Did the application hydrate?
- Did any first-party resource fail?
- Are expected elements present?
- Did the rendered page change?
Those are different layers of health.
Browser monitoring closes part of the gap
A real browser can observe what happens after the initial document arrives.
Witch uses browser checks alongside HTTP monitoring so incidents can include signals such as JavaScript errors, failed resources, DOM changes and visual changes.
That context matters.
A failed script alone may not mean the site is broken.
A failed first-party script followed by missing interface elements and a large visual change is a much stronger signal.
The useful question is not “did JavaScript fail?”
Websites generate noise.
Analytics scripts fail. Ad blockers interfere with third-party resources. Browser extensions cause console errors.
The useful question is:
Did something fail that changed what the user received?
That is why combining signals is more useful than treating every console error as an incident.
Keep the HTTP monitor
None of this makes HTTP monitoring less useful.
It catches DNS failures, TLS problems, server errors and downtime faster and more cheaply than launching a browser.
The better model is layered:
HTTP
↓
browser
↓
DOM
↓
visual stateEach layer tells you something the previous one cannot.
A green HTTP check means your server answered.
It should never be the final proof that your website still works.
Witch monitors the browser as well as the response, so you can see when a healthy server produces a broken page.