How to monitor a Convex backend from outside your dashboard

Your Convex dashboard shows green failure rates, yet customers cannot save data. That gap happens when you only watch in-app charts — not a URL the outside world can hit every few minutes. Convex gives you HTTP actions on a public .convex.site host separate from your Vercel frontend. This guide maps which surfaces matter, adds a GET health probe, splits frontend vs backend on your status page, and wires StillOnline with honest GET-only limits.

Quick answer

Monitor Convex from outside with GET on https://<deployment>.convex.site/health or a Vercel /api/health proxy — not only status.convex.dev. StillOnline sends HTTP GET only: on Free it checks the status code (not JSON fields), one URL, about five-minute interval. Return 503 when Convex is unhealthy.

Convex is backend-as-a-service: queries and mutations run on *.convex.cloud, while custom HTTP routes live on *.convex.site. The in-dashboard Health page tracks failure rate and scheduler lag — useful for you, invisible to customers. See Supabase backend monitoring and health check quickstart.

1. Map which Convex surfaces customers actually depend on

Customers rarely care which Convex function failed — they care whether signup, billing, or realtime sync works.

Do: list the one URL that means "our product backend is broken for paying users." Do not: treat status.convex.dev as proof your deployment and Vercel app work.

2. Create HTTP actions as external health probes

HTTP actions are plain web endpoints in convex/http.ts. They run on https://<deployment-name>.convex.site — note .convex.site, not .convex.cloud.

// Minimal GET /health (convex/http.ts)
import { httpRouter } from "convex/server";
import { httpAction } from "./_generated/server";
const http = httpRouter();
http.route({
  path: "/health", method: "GET",
  handler: httpAction(async () => {
    return new Response(JSON.stringify({ status: "ok" }), {
      status: 200, headers: { "Content-Type": "application/json" },
    });
  }),
});
export default http;

Deploy with npx convex deploy, then verify from outside:

curl -sS -o /dev/null -w "%{http_code}\n" https://YOUR-DEPLOY.convex.site/health

Do: keep the handler under about two seconds. Do not: require JWT on the probe path — StillOnline sends no Authorization header.

For deeper checks, add /ready that runs a cheap internal query and returns 503 when Convex data is unreachable. StillOnline Free evaluates the HTTP status code only.

Or proxy via Vercel /api/health — see Next.js health monitoring.

3. Separate Convex outages from your Vercel frontend

Many Convex stacks serve UI from Vercel while data lives on Convex. Monitoring only https://yourapp.com misses backend-only failures.

Do: label status page components "Web app (Vercel)" and "Backend (Convex)" when you have Pro checks for both. On Free you get one StillOnline URL — pick the path that best matches customer-visible downtime, usually /api/health that touches Convex the way production does.

4. Wire StillOnline checks and status page messaging

StillOnline runs scheduled HTTP GET probes, publishes a status page, and alerts after two consecutive failures. It does not open WebSocket sessions to .convex.cloud.

1. Sign in at stillonline.tech/app.
2. New project — name your product.
3. HTTP check — GET your health URL (.convex.site/health or app proxy), expect 200.
4. Status page — add component "Backend API" or "Convex".
5. One alert channel on Free — email, Telegram, or Slack.

Do: pre-write status copy: "We are investigating elevated errors on our Convex backend." Do not: promise JSON field checks on Free.

Honest Free limits: one project, one URL, about five-minute interval. Wait two to three probe cycles before calling an alert noisy. Pro ($9/mo) and Ultimate ($29/mo) add more URLs — pricing.

5. Reduce false positives when Convex throttles

Convex applies baseline network protection; application rate limits are your responsibility. A health route that hits the database on every probe, or a rate limiter that returns 429 to monitor IPs, can flip StillOnline red while users are fine.

Do: return 503 when Convex is genuinely unhealthy so Free tier sees it. Do not: return 200 with error JSON — StillOnline Free will stay green.

What's next

Ship GET /health, register it in StillOnline, split status components, rehearse a platform incident. Encode DB failures as 503 for honest Free monitoring.

Open stillonline.tech/app and paste your Convex health URL.

Related guides

• Supabase backend uptime monitoring
• Next.js SaaS health check monitoring
• Health check URL quickstart
• Public status page for SaaS

FAQ

Can StillOnline probe Convex HTTP actions without auth?

Yes for a dedicated public GET /health. Do not put API keys in the URL. Keep probes unauthenticated.

Should StillOnline monitor .convex.cloud or .convex.site?

Use .convex.site for HTTP GET probes. .convex.cloud is the WebSocket realtime API — StillOnline sends HTTP GET only.

What status page wording works for Convex outages with StillOnline?

Split components: "Backend (Convex)" vs "Web app." When status.convex.dev shows a platform incident, say so publicly and link their page.

Why false alerts when Convex throttles — and how does StillOnline react?

Common causes: 429 from your rate limiter, a slow database-heavy probe, or a brief platform error spike. Exclude /health from app rate limits and keep probes lightweight.

Monitor Convex directly or via Next.js /api/health in StillOnline?

Both work. Direct .convex.site/health is simplest. A Vercel proxy matches how browsers call your stack and keeps one customer-facing hostname on Free (one URL).

Does the Convex dashboard replace StillOnline external monitoring?

No. Dashboard Health helps you debug. Customers and on-call need external probes plus a status page when nobody is logged into Convex.