# How to Monitor Convex Uptime

> Convex is a reactive backend platform: a database, server functions and realtime sync in one, with HTTP actions for webhooks and public endpoints.

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

---

## Why Monitor Convex?

Convex runs your backend logic and data together, and keeps clients in sync in real time. When a deployment has a problem, every query, mutation and live update in your app is affected at once. HTTP actions give you a simple way to watch it from outside: a small health endpoint on your deployment's convex.site domain that an uptime monitor can check on a schedule.

## What to Monitor

- `your-deployment.convex.site/health` — A small HTTP action you add that returns 200 (and optionally runs a quick query) to confirm your deployment answers
- `your-app.com` — The frontend your users open, which can fail independently of Convex
- `your-deployment.convex.site/your-webhook-route` — Any HTTP action that third parties call, such as payment or auth webhooks

## What You Should Actually Do

1. Add a small HTTP action at /health that returns 200, optionally after a quick read query, and monitor its convex.site URL
2. Monitor every HTTP action that third parties call, like payment or auth webhooks; Convex doesn't automatically retry HTTP actions that fail
3. Monitor your frontend separately, so a hosting problem and a backend problem look different
4. Watch response times on the health action; a slow query or heavy function shows up as rising latency before it fails
5. Check your monitors right after every deploy; a function that throws fails for every user the moment it ships
6. Check status.convex.dev during incidents, but remember it covers the platform, not your functions or deploys

## Convex's Official Status Page

Convex publishes real-time status at https://status.convex.dev. Your own monitor complements it by catching connection-level issues, often before the status page updates.

## Takeaway

Convex keeps your app reactive by tying the frontend tightly to the backend, which also means backend problems show up everywhere at once, often as quiet spinners rather than loud errors. A monitored health action and your webhook routes give you a clear signal the moment something breaks.

## Frequently Asked Questions

### How do I monitor a Convex deployment with an uptime monitor?

Add an HTTP action (for example at /health) in convex/http.ts. HTTP actions are served on your deployment's convex.site domain, so the health URL looks like your-deployment.convex.site/health. Monitor that URL and expect a 200. To check the database too, have the action run a quick read query before responding.

### Should I monitor my Convex webhooks?

Yes. If a payment or auth provider calls a Convex HTTP action, failures there can lose events. Convex doesn't automatically retry HTTP actions that error, so you rely on the caller's retries. A monitor lets you catch problems while those retries are still happening.

### Can uptime monitoring catch realtime sync problems?

Indirectly. An HTTP monitor can't subscribe to live queries, but a health action that runs a real query catches the most common causes: a broken deploy, a failing function or an unreachable deployment.

### How is this different from status.convex.dev?

Convex's status page covers platform incidents. Your monitors cover your deployment: your functions, your latest deploy, your webhooks. A bad deploy will break your app without ever appearing on the vendor's status page.