Wasp is a full-stack web framework that uses a custom DSL to generate React + Node.js apps. It handles routing, authentication, database, and deployment — letting you focus on features instead of boilerplate. But once your Wasp app is live, you need to monitor it. This guide covers how to set up uptime monitoring for Wasp apps using Vigilmon.
What Wasp Generates
A compiled Wasp app has two deployable units:
- Client — a React/Vite app (static files or CDN-served)
- Server — a Node.js/Express server
You'll primarily want to monitor the server, since it handles auth, database queries, and your business logic. If the server goes down, the client shows errors even if it loads fine.
Adding a Health Route to Your Wasp Server
Wasp generates a standard Express server. Add a health check in your server setup:
// main.wasp
app MyApp {
server: {
setupFn: import setup from "@src/serverSetup.js"
}
}
// src/serverSetup.js
export const setup = async (app) => {
app.get('/health', (req, res) => {
res.json({ status: 'ok', timestamp: Date.now() })
})
}
After deploying, your health endpoint is at:
https://your-wasp-app-server.com/health
Finding Your Wasp Server URL
Deployed on Fly.io (Wasp default):
# Your server URL looks like:
https://your-app-name.fly.dev
Deployed on Railway:
https://your-app.up.railway.app
Deployed on Render:
https://your-app.onrender.com
The Wasp client and server get separate URLs — make sure you're monitoring the server URL.
Setting Up Vigilmon
Sign up free at vigilmon.online
Create a new monitor:
| Setting | Value |
|---|---|
| URL | https://your-wasp-server.fly.dev/health |
| Method | GET |
| Interval | 60 seconds |
| Expected status | 200 |
| Keyword | ok |
Set up email alerts.
Optionally add a second monitor for the client:
URL: https://your-wasp-app.netlify.app
Expected status: 200
Database Connection Health
Wasp uses Prisma + PostgreSQL (usually Supabase or Fly Postgres). Add a DB check to your health route:
import { db } from 'wasp/server'
export const setup = async (app) => {
app.get('/health', async (req, res) => {
try {
await db.$queryRaw`SELECT 1`
res.json({ status: 'ok', db: 'connected' })
} catch (err) {
res.status(503).json({ status: 'error', db: 'disconnected' })
}
})
}
Now your health check fails if the database is unreachable — a much more useful signal.
Auth Endpoint Monitoring
If authentication is critical to your app, add a second Vigilmon monitor for the auth endpoint:
URL: https://your-wasp-server.fly.dev/auth/me
Method: GET
Expected status: 401 (unauthenticated request returns 401, which means auth middleware is working)
A 401 means the auth middleware is running. A 500 or timeout means something deeper is broken.
Handling Fly.io Sleep (Free Tier)
Free Fly.io machines can spin down after inactivity. Vigilmon's 60-second ping keeps your server warm. If you're on Fly's free tier, set your Vigilmon check interval to 60 seconds — this keeps the machine warm without wasting credits.
For paid Fly plans, this isn't needed, but the monitoring is still valuable for catching actual crashes.
Wasp Background Jobs
If your Wasp app uses background jobs (via job in main.wasp), those run on the same server. If the server goes down, jobs stop. The health check covers this — if the server is down, Vigilmon alerts you, and you know jobs are also paused.
Alerting for Solo Developers
Most Wasp apps are indie projects — solo developers building side projects. The right alerting setup:
- Email (free on Vigilmon): you get a notification, fix it when you can
- Slack webhook: if you have a small team
For a hobby project, email is enough. For paying customers, consider adding a status page (Vigilmon paid) so users can self-serve.
Summary
Monitoring a Wasp app:
- Add
/healthroute inserverSetup.js - Deploy your Wasp app
- Create a Vigilmon monitor for the server URL
- Set email alerts
5 minutes of setup, permanent peace of mind.
Top comments (0)