Uptime monitoring for Node.js apps
External 1-minute checks for Node.js apps — Express, Fastify, Hono, NestJS, Next.js. Catch crashes from unhandled rejections, event-loop stalls, and deploy regressions before users do. Free for 5 monitors, $9/mo for 1-minute checks.
Why Node.js apps fail in unexpected ways
Node.js is single-threaded. One bad async path can crash the entire process. One blocking call can freeze every other request. A misconfigured promise can silently swallow errors that would have been a stack trace in any other runtime. Process managers like PM2 or systemd will restart a crashed process, but the time between crash and restart is downtime — and they don't catch the soft failures (event-loop stalls, hung requests, broken downstream dependencies) at all.
SitePulse probes your app from outside the host every minute. Crash, stall, or wrong-status-code — you get an email the moment it happens, with the recovery time when it's back.
What to monitor on a Node.js app
Production root URL
Your app's homepage or main route. Catches crashes, event-loop stalls, broken environment variables, and 5xx responses on the most-hit path.
/health endpoint
A lightweight route that runs SELECT 1 against your DB and a Redis PING if you use one. Catches DB pool exhaustion, network partitions, and auth credential issues.
Critical API routes
Don't just monitor /. If /api/auth/login or /api/checkout matters more than the homepage, monitor those too. SitePulse can match a keyword in the response to verify the route is fully working, not just returning 200.
Background workers
Bull / BullMQ / Agenda workers don't have HTTP endpoints by default. Add a tiny Express server inside your worker that returns 200 while the queue is processing. Monitor it. Workers die silently more often than web servers.
Webhooks endpoints
If you receive Stripe / GitHub / Resend webhooks, monitor those endpoints. A broken webhook receiver silently drops events and corrupts your data — and PM2 will report 'all good.'
Public status page
Enable SitePulse's free status page. When something goes wrong, customers see real status instead of guessing — and you don't have to write the page yourself.
A solid /health endpoint in 20 lines
For Express:
import express from "express";
import { db } from "./db";
import { redis } from "./redis";
const app = express();
app.get("/health", async (req, res) => {
try {
await Promise.all([
db.query("SELECT 1"),
redis.ping(),
]);
res.json({ ok: true, ts: Date.now() });
} catch (err) {
res.status(503).json({
ok: false,
error: (err as Error).message,
});
}
});
app.listen(3000);For Fastify, Hono, NestJS, or Next.js it's the same idea — just the file location and route registration syntax differ. Point SitePulse at https://yourapp.com/healthand you'll catch DB and cache failures within one probe interval.
Set it up in 60 seconds
- Sign up — free, no credit card.
- Add your Node.js app URL (custom domain or platform URL).
- Add /health if you have one, plus any critical API routes.
- Check interval: 5 min on Free, 1 min on Pro ($9/mo).
- Email alert fires the moment any monitor goes red.
What you get
1-minute checks
On Pro plan ($9/mo). Catches event-loop stalls and crashes that PM2 wouldn't even log.
SSL expiry alerts
Email 14 days before your TLS certificate expires. Saves an embarrassing outage.
Public status page
Free on every plan. Shareable URL with 30-day uptime history.
Add monitoring before your next Node.js deploy
5 monitors, 5-minute checks, email alerts, public status page — free forever. No credit card.
Frequently asked questions
I already have process managers like PM2 or systemd. Why use external monitoring?+
PM2 / systemd / Kubernetes restart your process when it crashes. They don't tell you whether your app is actually responding correctly to user requests. A Node.js process can be 'running' (PM2 reports OK) yet returning 500s on every request because of a config bug, blocked event loop, or downstream dependency failure. SitePulse hits your URL from outside the box — exactly as a user does — and alerts you the moment something's wrong.
What's the right way to build a /health endpoint in Node.js?+
Lightweight, fast, and exercising your real dependencies. Run a cheap database query (SELECT 1), test critical caches if you have them (Redis PING), and return 200 with JSON if all checks pass, 503 if any fail. Avoid heavy work — your /health should respond in under 100ms. Don't include /health in any auth middleware (your monitor needs anonymous access).
How does SitePulse catch unhandled promise rejections that crash my app?+
When your Node.js process crashes from an unhandled rejection, your HTTP server stops responding. SitePulse's next probe fails and you get an email within one probe interval (1 minute on Pro, 5 minutes on Free). The fix is still in your code (a domain-level handler or fixing the root cause), but SitePulse turns the silent crash into a visible alert. PM2/systemd will restart the process, but during the gap users see errors — SitePulse measures that gap.
What about event-loop stalls?+
If a long synchronous operation blocks the event loop, your HTTP server can't respond to incoming requests. SitePulse's probe times out, marking the monitor down. This is one of the most useful real-world signals: a CPU-bound operation (sync crypto, a giant JSON.parse, a regex catastrophe) that doesn't crash the process but freezes it. Catch it from the outside — same as your users would.
Does SitePulse work with serverless Node (Lambda, Vercel, Cloudflare Workers)?+
Yes — SitePulse just hits a public URL. Whether it's served by a long-running EC2 process, a Lambda Function URL, a Vercel function, or a Cloudflare Worker, the probe is identical. The cold-start behavior of serverless platforms can produce occasional slow responses; set the failure threshold to 2 if you see flapping from cold starts.
Should I monitor Express, Fastify, Hono, NestJS, etc. differently?+
No — they all expose HTTP endpoints, which is what SitePulse monitors. The only framework-specific decision is where to put your /health route. In Express it's app.get('/health'), in Fastify it's fastify.get('/health'), in NestJS it's a dedicated controller, in Next.js it's app/api/health/route.ts. The probe is the same; only the implementation file changes.