Backend

When PocketBase Goes Down: A Survival Guide for Your Team

You picked PocketBase because it's simple. One binary, one command, and you have a backend — auth, database, file storage, realtime, all running. No Docker, no Kubernetes, no managed service bill. It's the fastest path from nothing to a working backend, and for a solo developer that speed is everything. But there's a trade built into that simplicity: no one is watching it for you. When PocketBase runs on a managed platform like Railway or Fly.io, at least the platform might restart a crashed process. When it runs on a raw VPS — which is how most PocketBase projects run — a crash at 2 AM stays crashed until someone manually restarts it. And because PocketBase stores everything in a local SQLite file, there's no external database health check that might catch the problem indirectly. The gap between 'it was working when I deployed it' and 'it's working right now' is the gap that monitoring closes.

View as Markdown

What Happens on Your Team

The Solo Developer Running PocketBase on a VPS

Deployed PocketBase on a $5 VPS. The process crashes overnight — maybe an OOM kill, maybe a failed disk write, maybe the VPS itself rebooted. Nobody notices until morning.

The real cost: Users hit a connection refused error. Sign-ups fail. Data from realtime subscribers is lost. The developer wakes up to support messages instead of a clean morning.

What they should have had: A monitor on the PocketBase health endpoint that alerts via Telegram the moment the process stops responding, so a restart happens in minutes, not hours.

The Small Team Using PocketBase as a Mobile Backend

PocketBase powers the API for a mobile app. The SQLite database file grows until the disk is full, or a migration breaks the schema. The app starts throwing errors on every request.

The real cost: Every user of the mobile app sees failures. App store reviews mention crashes. The team doesn't find out until the bug reports pile up because there's no server monitoring in place.

What they should have had: Monitors on the API endpoints the mobile app actually calls, with response time thresholds so slowdowns are caught before they become full outages.

The Agency Deploying PocketBase for Client Projects

Manages multiple PocketBase instances across different VPS providers for different clients. One instance goes down, but the agency doesn't notice because they're focused on a different client's project.

The real cost: The client discovers their own downtime before the agency does. Trust is damaged. The agency looks unprofessional — exactly the opposite of what a managed service should deliver.

What they should have had: A monitor per client instance with a shared status page, so both the agency and the client can see uptime status in real time.

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

What You Should Actually Do

  1. 1Monitor /api/health for a 200 response — this confirms the PocketBase process is alive and the SQLite database is accessible
  2. 2Set your check interval to match your tolerance for downtime — 5 minutes is fine for most side projects, 1-2 minutes for production apps
  3. 3Alert via Telegram or webhook for immediate notification — email is too slow for a self-hosted service with no auto-restart
  4. 4Create a status page so your users can check before opening a support ticket or assuming the worst
  5. 5Set maintenance windows before planned VPS reboots, OS updates, or PocketBase version upgrades to avoid false alerts

The 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.

Get started today

Your Sites Deserve Better Monitoring.

Know when your site goes down before your customers do.

Start Monitoring →See Pricing

Plans from $5/month · 14-day money-back guarantee.