Your health check is green. Is the app actually usable?

Yes, with a limit worth stating plainly. Sitewatch checks the initial page and verifies every file it references — bundles, styling, fonts, third-party scripts. It does not execute JavaScript, so it cannot test client-side routing or confirm the app became interactive. What it does catch is the reason most SPAs break in production: a file the app needs is no longer being served.

It detects the most common cause, not the symptom. When hydration fails because the bundle the page asks for is missing or is being served as something else, Sitewatch catches that on the next check and names the file. If hydration fails purely because of a runtime error in code that loaded correctly, that is an error tracker's job — the two tools cover different halves of the problem.

Error tracking reports exceptions from inside sessions that already loaded, which means someone had to hit the problem first. Sitewatch checks from outside, on a schedule and after deploys, and catches failures where nothing throws at all — a file that stopped being served, a page that quietly changed, an endpoint that stopped answering. Most teams run both.

No. APM watches server-side performance, traces and queries. Sitewatch watches what actually reaches the browser. They are complementary, and neither one covers the other's failures.

Not currently. Sitewatch monitors publicly reachable pages — which for a web app covers the login and signup flows, marketing pages, docs and public entry points. Authenticated monitoring is not something it does today.

Any of them — Next.js, Nuxt, Remix, SvelteKit, Astro, Rails, Django and the rest. The check happens from outside, so the framework only matters for tailoring the diagnosis, which happens automatically once Sitewatch recognises the stack.

On Pro, Sitewatch checks from EU and US, so an edge location serving a stale or corrupted file shows up instead of being hidden by the region your team happens to sit in.