Monitoring SolidStart Applications with Vigilmon: Server Routes, Health Endpoints & SSR Alerting

SolidStart is the full-stack SSR framework for SolidJS — it handles server-side rendering, file-based routing, API routes, and deployment adapters for Vercel, Netlify, Cloudflare Workers, and Node.js. Unlike a static SolidJS client app, SolidStart has a server that can fail, restart, or fall behind. Vigilmon monitors that server from the outside, the same way your users hit it, and alerts you the moment it stops responding correctly.

Note: This tutorial targets SolidStart (server routes, SSR). If you're monitoring a client-side-only SolidJS SPA, see the SolidJS monitoring tutorial.

What You'll Build

A SolidStart API route at /api/health that checks server-side dependencies
A Vigilmon HTTP monitor targeting the health route
Alerting configuration for SSR failures and slow rendering

Prerequisites

A SolidStart application (v1.0+)
App deployed to a reachable URL (Node.js server, Vercel, Netlify, etc.)
A free account at vigilmon.online

Step 1: Add a Health API Route to SolidStart

SolidStart API routes live in src/routes/api/. Create a health.ts file — it will be served at /api/health.

Basic health endpoint

// src/routes/api/health.ts
import { APIEvent } from "@solidjs/start/server";

export async function GET(event: APIEvent) {
  const checks: Record<string, string> = {};
  let ok = true;

  // Check an environment variable is set (catches misconfigured deploys)
  if (!process.env.DATABASE_URL) {
    checks.config = "DATABASE_URL missing";
    ok = false;
  } else {
    checks.config = "ok";
  }

  // Probe a downstream dependency
  try {
    const res = await fetch(process.env.DOWNSTREAM_API + "/ping", {
      signal: AbortSignal.timeout(3000),
    });
    checks.downstream = res.ok ? "ok" : `http_${res.status}`;
    if (!res.ok) ok = false;
  } catch (err: any) {
    checks.downstream = `error: ${err.message}`;
    ok = false;
  }

  return new Response(
    JSON.stringify({ status: ok ? "ok" : "degraded", checks }),
    {
      status: ok ? 200 : 503,
      headers: { "Content-Type": "application/json" },
    }
  );
}

With a database check (using Drizzle + Postgres)

// src/routes/api/health.ts
import { APIEvent } from "@solidjs/start/server";
import { db } from "~/lib/db";
import { sql } from "drizzle-orm";

export async function GET(event: APIEvent) {
  const checks: Record<string, string> = {};
  let ok = true;

  try {
    await db.execute(sql`SELECT 1`);
    checks.database = "ok";
  } catch (err: any) {
    checks.database = `error: ${err.message}`;
    ok = false;
  }

  return new Response(
    JSON.stringify({
      status: ok ? "ok" : "degraded",
      environment: process.env.NODE_ENV,
      checks,
    }),
    {
      status: ok ? 200 : 503,
      headers: { "Content-Type": "application/json" },
    }
  );
}

Verify the route works locally:

npx vinxi dev
curl http://localhost:3000/api/health
# {"status":"ok","checks":{"database":"ok"}}

Step 2: Test Across Deployment Adapters

SolidStart's adapter system means the same code can run on Node.js, Vercel Edge Functions, Netlify, or Cloudflare Workers. The /api/health route works identically across adapters — but check these adapter-specific considerations:

Node.js adapter (@solidjs/start/node):

Health route runs in the same process as SSR; if Node.js is down, both fail together.
Set Vigilmon timeout to 10 seconds.

Vercel adapter (@solidjs/start/vercel):

API routes run as serverless functions; health route may cold-start.
Set Vigilmon timeout to 20 seconds.

Cloudflare Workers adapter (@solidjs/start/cloudflare):

No cold starts, but Worker CPU time limits apply (50 ms on free, 30 s on paid).
Set Vigilmon timeout to 10 seconds.

Netlify adapter (@solidjs/start/netlify):

Runs as Netlify Functions; cold starts apply.
Set Vigilmon timeout to 20 seconds.

Step 3: Configure the Vigilmon HTTP Monitor

Log in to Vigilmon → Add Monitor → HTTP.
URL: https://your-solidstart-app.com/api/health.
Check interval: 60 seconds.
Response timeout: 15 seconds (adjust for your deployment adapter — see above).
Expected status: 200.
JSON assertion: path status, expected value ok.
Click Save.

Vigilmon will start probing your SolidStart health route from an external location. The first check runs within a minute of saving.

Step 4: Monitor SSR Page Rendering

The /api/health route verifies server-side logic, but SSR rendering itself can fail independently — a broken <Suspense> boundary, a server component that throws, or a hydration mismatch can break rendered pages while the API route still returns 200.

Add a second monitor for your home page or a key SSR page:

Add Monitor → HTTP.
URL: https://your-solidstart-app.com/ (or your most critical page).
Expected status: 200.
Keyword: a phrase that only appears in the fully rendered HTML (e.g., your app's <title> tag content, or a specific heading).
Check interval: 60 seconds.

If SolidStart's SSR pipeline breaks, the page will either return a 500 or render an empty/error body — this keyword check catches both cases.

Step 5: Alert Configuration

Set up alert channels in Vigilmon under Settings → Notifications:

| Monitor | Trigger | Alert | Response | |---|---|---|---| | /api/health returns 503 | Immediate | Email + Slack | Check logs, DB connection | | /api/health times out | Immediate | Email + Slack | Check server CPU/memory | | SSR page keyword missing | Immediate | Email | Check SSR rendering pipeline | | SSR page returns 500 | Immediate | Email + Slack | Deploy rollback candidate |

Alert after: 1 consecutive failure for API routes (they're stable), 2 for SSR pages (a single render failure can be transient during deploys).

Re-notify: every 5 minutes while the issue persists.

Step 6: Alerting During Deploys

SolidStart on Node.js may have a brief downtime window during deploys when the old process stops and the new one starts. To avoid false positive alerts:

Use a process manager (PM2 or systemd) with graceful reload, which starts the new process before stopping the old one:
```
pm2 reload solidstart-app --update-env
```
In Vigilmon, set Notify after: 2 consecutive failures. A single missed check during a rolling deploy won't page on-call.
Use Vigilmon's maintenance windows if you have planned deploy windows — alerts are suppressed during the window and resume automatically.

What Vigilmon Catches That Browser DevTools Miss

| Scenario | DevTools | Vigilmon | |---|---|---| | Server process crashes | Only if you're on the page at the time | HTTP monitor fires within 60–120 s | | Database connection lost | Shows as SSR error to user | /api/health returns 503, monitor fires | | SSR rendering throws unhandled error | Manual inspection | Keyword monitor catches missing content | | Deployment causes downtime | Noticed by users | Monitor catches it before most users do | | Memory leak causes slow responses | Not visible | Response timeout fires alert |

SolidStart's server-side capabilities are what make it powerful — and what make external monitoring essential. A broken server route or failed SSR render is invisible until a user hits it. Vigilmon catches it first.

Start monitoring your SolidStart app in under 5 minutes — register free at vigilmon.online.