# How to Monitor Appwrite Uptime

> Appwrite is an open-source backend platform with auth, databases, storage, functions and messaging, available as Appwrite Cloud or as a self-hosted install.

*Source: https://monitoristic.com/monitor/appwrite*

---

## 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/version` — Appwrite's public version endpoint, a lightweight check that the API is up and answering
- `your-app.com` — The app your users open, which can fail even when the Appwrite API is fine
- `your-app.com/api/your-key-route` — A route that reads from your Appwrite database, to catch failures beyond basic reachability

## What You Should Actually Do

1. Monitor 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. If you self-host, also monitor the URL in front of your reverse proxy; a proxy error and an Appwrite failure need different fixes
3. Add a monitor on an app route that reads real data, to catch permission and configuration problems a version check can't see
4. Track response times; a self-hosted install running out of memory or disk usually slows down before it fails
5. Send alerts to your phone; an Appwrite outage takes down sign-in and data for your whole app at once
6. On 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 https://status.appwrite.online. Your own monitor complements it by catching connection-level issues, often before the status page updates.

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