Backend

When Appwrite Goes Down: A Survival Guide for Your Team

A user emails: 'I can't log in.' Then another. Your frontend loads, the login form renders, and every sign-in attempt spins and fails. You run the self-hosted Appwrite stack on a single VPS, and after an automatic OS update last night, one of its containers didn't come back up. The server responds to ping. The API does not.

View as Markdown

What Happens on Your Team

The Self-Hosting Developer

SSHes in, runs docker ps, and finds the stack half up. Restarts it, and everything works. Then realizes it was broken for most of the night, and the first signal was a user email.

The real cost: A self-hosted backend has no vendor watching it. A stopped container, a full disk or an expired certificate on your reverse proxy can take Appwrite down silently, and nobody notices until someone tries to use the app.

What they should have had: A monitor on the Appwrite endpoint's /v1/health/version route. If the API stops answering, the alert arrives within one check interval instead of with the morning's support emails.

The Mobile App Developer

App store reviews start mentioning 'can't sign in'. The app binary hasn't changed in weeks, so the problem has to be on the backend, but there's no dashboard showing when it started.

The real cost: Mobile users can't refresh a broken web page; they just leave a one-star review. And without a timeline, you can't tell whether the issue lasted ten minutes or ten hours.

What they should have had: Uptime history on the Appwrite API. When reviews mention an outage, you can see exactly when it started and ended, and whether it's still happening.

The Agency Lead

Runs Appwrite Cloud projects for several clients. One client calls about errors; the team checks Appwrite's status page, sees nothing, and spends an hour before finding a permissions change that broke one collection.

The real cost: A healthy platform doesn't mean a healthy project. Misconfigured permissions, deleted keys and broken functions are project-level failures the vendor's status page will never show.

What they should have had: A monitor per client on a route that actually reads that client's data. The platform check says Appwrite is up; the data check says this project works.

Why Monitor Appwrite?

Appwrite sits under your whole app: when it's unreachable, sign-in, data loading and file uploads fail together. On Appwrite Cloud you depend on Appwrite's platform; on a self-hosted install you also depend on your own server, Docker containers and the reverse proxy in front of them. Either way, an outside monitor is how you find out before your users do.

What to Monitor

your-appwrite-endpoint/v1/health/versionAppwrite's public version endpoint, a lightweight check that the API is up and answering
your-app.comThe app your users open, which can fail even when the Appwrite API is fine
your-app.com/api/your-key-routeA route that reads from your Appwrite database, to catch failures beyond basic reachability

What You Should Actually Do

  1. 1Monitor your Appwrite endpoint's /v1/health/version route; it answers without an API key, so it's a safe, lightweight reachability check (the fuller /v1/health endpoints require an API key, so don't point a public monitor at them)
  2. 2If you self-host, also monitor the URL in front of your reverse proxy; a proxy error and an Appwrite failure need different fixes
  3. 3Add a monitor on an app route that reads real data, to catch permission and configuration problems a version check can't see
  4. 4Track response times; a self-hosted install running out of memory or disk usually slows down before it fails
  5. 5Send alerts to your phone; an Appwrite outage takes down sign-in and data for your whole app at once
  6. 6On Appwrite Cloud, check status.appwrite.online during incidents; for self-hosted installs, your own monitors are the only status page you have

Appwrite's Official Status Page

Appwrite publishes real-time status at status.appwrite.online. Monitoristic doesn't replace this — it complements it. The official page tells you when Appwrite reports an issue. Your own monitor tells you when your connection is affected, often before the status page updates. You also get push alerts instead of checking a webpage manually.

The Takeaway

Appwrite gives you a complete backend, cloud or self-hosted. On Cloud, external monitoring catches what's specific to your project. Self-hosted, it's the only thing watching at all. Either way, a version check plus one real data route tells you within minutes when your backend stops answering.

Frequently Asked Questions

Which Appwrite endpoint should I monitor?
Start with /v1/health/version on your Appwrite endpoint. It responds without authentication and confirms the API is up. Appwrite's other health endpoints check internal components but require an API key with health permissions, which you shouldn't expose to a public monitor. Pair the version check with a route in your own app that reads real data.
Is monitoring different for Appwrite Cloud and self-hosted?
The checks are the same; the stakes differ. On Appwrite Cloud, Appwrite runs the platform and publishes a status page, so your monitors catch project-level issues. Self-hosted, you run everything, so your monitors are the only thing that will notice a stopped container, full disk or expired certificate.
Can I monitor Appwrite Functions?
Yes, if the function has an HTTP endpoint. Monitor its URL and set the expected status code it returns when healthy. That catches failed deployments and runtime errors that a general API check would miss.
How is this different from Appwrite's status page?
Appwrite's status page reports incidents on Appwrite Cloud. It can't see your self-hosted server, and it won't show problems specific to your project, like broken permissions or a deleted key. Your own monitors cover both.

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.