How to monitor Remix and SvelteKit SaaS apps (health routes + SSR)

Your homepage loads from a CDN and returns 200 while logged-in SSR routes throw 500. The uptime monitor pings / and stays green. Monitor Remix and SvelteKit uptime for SaaS by probing framework health routes and at least one SSR path, not just static assets.

Quick answer

CDN greens lie when SSR or API routes fail. Add Remix /health on your Node server and SvelteKit /api/health via +server.ts returning JSON with 200 or 503. Point StillOnline at the health URL from outside your network. On Fly.io match fly.toml http_service.checks path. StillOnline Free checks HTTP status only on one URL every five minutes.

For Next.js patterns, read Next.js SaaS health check monitoring. For Fly-specific probe setup, see uptime monitoring on Fly.io.

1. SSR health vs static asset CDN greens

A static marketing page can be healthy while your app shell fails authentication or database calls.

Do: monitor a dedicated health route plus one critical SSR path if revenue depends on it. Do not: rely on homepage 200 alone.

StillOnline sends GET from outside and evaluates HTTP status codes on Free tier — not JSON fields. Return 503 when readiness checks fail.

2. Framework-specific /health route patterns

Remix on Node with Express adapter — add /health on the custom server before the Remix handler:

app.get("/health", (_req, res) => {
  res.status(200).json({ status: "ok", timestamp: new Date().toISOString() });
});
app.all("*", remixHandler);

Add DB readiness on /ready with a timeout and return 503 when the pool fails.

SvelteKit — create src/routes/api/health/+server.ts:

import { json } from '@sveltejs/kit';
import type { RequestHandler } from './$types';
export const GET: RequestHandler = async () => {
  return json({ status: 'ok', timestamp: new Date().toISOString() });
};

Remix on Vercel (no Express server) — create app/routes/health.tsx:

export const loader = async () => {
  return Response.json({ status: "ok", timestamp: new Date().toISOString() });
};

curl -sS -o /dev/null -w "%{http_code}\n" https://app.example.com/api/health

Do: keep health routes unauthenticated. Do not: reuse session middleware that redirects probes to /login (302 looks like success to naive checks).

3. Serverless vs Node adapter differences

# fly.toml excerpt
[[http_service.checks]]
grace_period = "10s"
interval = "30s"
timeout = "5s"
method = "GET"
path = "/api/health"

Fly routes traffic away from Machines that fail checks — platform readiness, not a substitute for StillOnline. Serverless cold starts can make the first probe after idle slow. Keep handlers tiny.

Do: respond in under two seconds for external monitors. Do not: run heavy DB migrations inside the health handler.

4. StillOnline checks for full-stack JS frameworks

1. Sign in at stillonline.tech/app and create a project.
2. Add check with full HTTPS URL, e.g. https://app.example.com/api/health — method GET, expect 200.
3. Wait 2–3 probe cycles (Free interval about five minutes) before tuning.
4. Enable alerts — Free allows one channel. Pro ($9/mo) adds more URLs — pricing.
5. Share status page link in support docs and incident posts.

Do: monitor the same region customers use. Do not: point at preview deployments.

StillOnline complements platform checks: you catch certificate expiry and DNS regressions Fly or Vercel dashboards may not show. StillOnline debounces two consecutive failures before alerting.

5. Compare Next.js, Remix, and SvelteKit

1. Document canonical health URLs in README.
2. Verify 503 when database stopped in staging.
3. curl from home network, not only CI.
4. Exclude health from auth middleware.
5. Add second check on paid tier if marketing site is separate host.

Do: align Fly path and StillOnline URL exactly. Do not: monitor trailing-slash redirects without testing final status code.

What's next

You have health routes that prove SSR works and a StillOnline check that pages you when the public URL fails. Add Telegram alerts via our Telegram uptime guide and link the status page from your footer.

Open StillOnline, paste your Remix or SvelteKit health URL, and confirm two green probe cycles before calling it done.

Related guides

• Next.js SaaS health check monitoring
• Uptime monitoring on Fly.io
• Health check URL quickstart
• REST API uptime status

FAQ

Should StillOnline probe SSR HTML or JSON health for Remix/SvelteKit?

Use JSON /health or /api/health for the primary StillOnline check. Add a second monitor on a critical SSR page only if sessions are central to downtime definition.

What adapter pitfalls affect StillOnline on Fly and Vercel?

Fly requires matching http_service.checks path and internal_port. Vercel serverless cold starts can delay first response — keep health handlers lightweight.

Should StillOnline monitor homepage or /api/health?

Monitor /api/health or /ready. Homepage CDN greens hide API failures.

Remix on Vercel without Express — what URL for StillOnline?

Use a Remix resource route for /health instead of server.ts. Test the production URL StillOnline will probe.

SvelteKit edge vs node for health with DB — StillOnline implications?

Pin Node runtime on the health route if you need database drivers incompatible with edge.