# How to Monitor PocketBase Uptime > PocketBase is an open-source backend in a single binary — SQLite database, auth, realtime subscriptions, and file storage, all in one executable. Popular with solo developers and small teams for MVPs, side projects, and mobile backends. *Source: https://monitoristic.com/monitor/pocketbase* --- ## Why Monitor PocketBase? PocketBase is self-hosted, which means you are the SLA. There is no vendor status page, no incident alerts from a provider, and no ops team watching your process. If the binary crashes, the VPS runs out of memory, or the disk fills up, nobody knows until a user complains — or until your monitor catches it. ## What to Monitor - `undefined` — undefined - `undefined` — undefined - `undefined` — undefined ## What You Should Actually Do 1. Monitor /api/health for a 200 response — this confirms the PocketBase process is alive and the SQLite database is accessible 2. Set your check interval to match your tolerance for downtime — 5 minutes is fine for most side projects, 1-2 minutes for production apps 3. Alert via Telegram or webhook for immediate notification — email is too slow for a self-hosted service with no auto-restart 4. Create a status page so your users can check before opening a support ticket or assuming the worst 5. Set maintenance windows before planned VPS reboots, OS updates, or PocketBase version upgrades to avoid false alerts ## PocketBase's Official Status Page PocketBase publishes real-time status at null. Your own monitor complements it by catching connection-level issues, often before the status page updates. ## Takeaway PocketBase gives you an entire backend in a single binary — but it can't watch itself. When the process crashes, the disk fills up, or the VPS reboots, there's no vendor status page and no platform alert. An external monitor on /api/health is the difference between finding out in 60 seconds and finding out from your users the next morning. ## Frequently Asked Questions ### Does PocketBase have built-in monitoring? PocketBase exposes a /api/health endpoint that returns the server's health status, but it doesn't actively monitor itself or send alerts. If the process crashes or the server goes down, there's no built-in mechanism to notify you. External monitoring is the only way to get alerts. ### Why can't I just use a process manager like systemd to watch PocketBase? A process manager can restart a crashed process, and you should use one. But it can't tell you about a PocketBase instance that's running but broken — returning errors, unable to write to the database, or stuck in a bad state. And it can't alert you when the entire VPS is unreachable. External monitoring catches what process managers miss. ### What's the best endpoint to monitor on PocketBase? /api/health is the best starting point — it confirms the process is running and the database is accessible. If your app has critical API endpoints (auth, data retrieval), consider monitoring those too, since a healthy /api/health doesn't guarantee every collection or hook is working correctly. ### Should I monitor PocketBase differently on Railway or Fly.io vs a raw VPS? The monitoring itself is the same — check /api/health for a 200 response. But on a managed platform, the platform may auto-restart crashed processes, so you're more likely to catch intermittent issues (repeated short outages) than prolonged downtime. On a raw VPS without auto-restart, a crash stays crashed until you fix it, making fast alerting even more critical.