Uptime monitoring for Next.js apps
Hit your homepage, your /api routes, your ISR pages, and your edge functions every minute. Get an email the moment a deploy regresses. Public status page included. Free for 5 monitors.
Why monitor your Next.js app?
A deploy can succeed on Vercel and still break your app. Env vars get renamed, a Supabase query times out, an edge function fails to cold-start in a region, ISR pages serve stale data, a middleware redirect loops. None of that shows up in Vercel's status — but users hit it within seconds.
SitePulse hits your URLs from the outside, the same way users do, on a 1-minute interval. If anything regresses, you get an email before customers send one.
What to monitor in a Next.js app
Homepage + landing pages
Your /, /pricing, /docs, and any other top-of-funnel pages. Catches CDN, build, and ISR issues. Status code + keyword match on a page-specific phrase ('Get started for free') catches regressions HTML-status-200-but-broken-content can't.
Public /api health check
Build /api/health that does a real (but cheap) DB round-trip and returns 200 with a JSON heartbeat. Monitor it. Catches Supabase / RLS / connection-pool issues without needing auth.
Customer-facing /api endpoints
Webhooks, /api/checkout, /api/search — anything customers or third parties depend on. A deploy that breaks one of these without affecting the homepage is the worst kind of outage. Monitor each.
ISR pages with revalidation
If you have pages that revalidate on a tag or interval, a stale-data bug is silent until a customer notices. Add keyword monitoring on the relevant page to assert it shows fresh content.
60-second setup
- Sign up with email or Google. No card.
- Click "Add monitor" — paste your homepage URL.
- Repeat for /api/health, /pricing, and any other critical routes.
- Pick check interval (5-min on Free, 1-min on Pro).
- Optional: enable keyword matching on a phrase that should appear on the page when it's healthy.
- Save. Done. Email lands the moment anything goes red.
Example: /api/health for Next.js
A health endpoint that does a real DB round-trip but doesn't require auth. Monitor this and you'll catch most app regressions:
// src/app/api/health/route.ts
import { NextResponse } from "next/server";
import { createSupabaseServiceRole } from "@/lib/supabase/server";
export const runtime = "nodejs";
export const dynamic = "force-dynamic";
export async function GET() {
try {
const supabase = createSupabaseServiceRole();
// A trivial query that exercises the connection without
// depending on any specific row existing.
const { error } = await supabase
.from("profiles")
.select("id", { count: "exact", head: true })
.limit(1);
if (error) throw error;
return NextResponse.json({ ok: true, ts: Date.now() });
} catch (e) {
return NextResponse.json(
{ ok: false, error: (e as Error).message },
{ status: 503 },
);
}
}Then in SitePulse, monitor https://your-app.com/api/health with optional keyword ok required. Now you know within 60 seconds when a DB pool, env var, or schema migration breaks the app.
What you get
1-minute checks
On Pro plan ($9/mo). Free plan checks every 5 minutes — enough for side projects.
Email alerts
Instant email when a monitor flips. Configurable failure threshold to suppress flakes.
Public status page
Free on every plan. Custom slug, embeddable, indexed by Google. Builds trust with users.
Set it up before your next deploy
5 monitors, 5-minute checks, email alerts, public status page — free forever. No credit card.
Frequently asked questions
Why do I need uptime monitoring on top of Vercel's deploy status?+
Vercel's status page tells you if Vercel is up. SitePulse tells you if YOUR app is up. They're different. A deploy can succeed (Vercel happy) while your /api/checkout route 500s because an env var is missing or a Supabase query times out. SitePulse hits your URLs the same way users do, so you find out when those break — not just when Vercel itself breaks.
What should I monitor in a typical Next.js app?+
Four types of routes worth monitoring: (1) the homepage and 1-2 critical landing pages — catches CDN / build issues; (2) signed-in routes via a public health-check endpoint that exercises Supabase / DB — catches database / auth issues; (3) any /api endpoints customers depend on (checkout, webhook receivers, search) — catches API regressions; (4) any ISR pages with revalidation — catches stale-data issues. Status code 200-399 + optional keyword match on the body is enough for most cases.
Can I monitor edge functions and middleware?+
Yes — edge runtime functions are just URLs from SitePulse's perspective. Same setup. The one gotcha: middleware that does redirects (e.g., locale routing or auth gates) returns 3xx by default. SitePulse's default 'expected status range' is 200-399 so redirects count as up. If you want to assert a specific status, narrow the range in monitor settings.
How do I monitor /api routes that need authentication?+
Two patterns: (1) build a public /api/health endpoint that does a representative DB query but doesn't require auth — most teams do this; (2) generate a long-lived API token your monitor includes in headers — supported via custom headers in monitor settings. Option 1 is simpler and what we recommend for indie projects.
Will it catch a broken deploy?+
Usually within 1 minute on Pro plan. The flow: you deploy, Vercel rolls out, SitePulse's next probe (within 60 seconds) hits your URLs, if any return 500 / 503 / time out, an email arrives within seconds. For deploys that subtly break a sub-feature (one specific page returns the wrong HTML), enable keyword matching on the relevant page so the probe asserts page content, not just status code.
Does the status page work with my custom domain?+
Yes. Status pages live at sitepulse.satosushi.co/status/your-slug today. Custom domains for status pages are on the roadmap. The current URL is shareable, indexable, and free on every plan.