Convex status

How we check Convex

We watch api.convex.dev from all five of our probe regions, every 2 minutes. A region that sees a failure does not make this page say "down" on its own: a second region has to agree first, the same confirmation rule every YoPingMe monitor uses.

Every Convex deployment answers on its own generated hostname, so no public endpoint represents customers as a group. We watch the platform API, which is what the CLI and deploy tooling talk to, and we pin the response an unauthenticated request receives rather than assuming any particular code means health.

What is Convex?

Convex is a backend platform that combines a document database, server functions, and realtime subscriptions into one system. Queries written as functions are executed on the server, and clients subscribing to them receive updates automatically when the underlying data changes, without polling or a separately managed websocket layer. The effect is that a reactive interface stops being an architecture problem and becomes the default behaviour.

That reactivity is the first thing to understand when something appears broken. Because updates arrive over a persistent connection rather than being fetched, a dropped connection does not produce an error. It produces a page that keeps showing the last data it received, which looks entirely normal until someone notices a number that should have changed. A user reporting stale information rather than a failure is the characteristic symptom, and it points at the connection rather than at the backend. Refreshing re-establishes it, which is why that unhelpful piece of advice actually works here.

The transactional model is the second thing worth knowing. Mutations run as serializable transactions, so the platform will reject one that would conflict rather than allowing an inconsistent write, and the client retries. This is correct behaviour that can be mistaken for flakiness when it appears in logs. A rising rate of conflicts usually means several clients are writing the same document, which is a data modelling question about how documents are split rather than a signal about platform health.

Scheduled functions deserve their own attention after any incident. Because they run on the platform rather than being triggered by a user, nobody is watching when they fail, and an application that assumes a nightly job ran will act on data that was never updated. The functions log records what actually executed, and checking it after a period of unavailability is worth more than reading any status page, including this one.

The last thing to say is about the shape of the dependency. Convex holds the database, the server logic, and the realtime layer together, which is what makes it pleasant to build on and also concentrates the risk. There is no meaningful sense in which part of an application keeps working while Convex does not, the way a static site survives an API outage. That is a reasonable trade for the productivity, and it is worth making deliberately rather than discovering during the first incident.

Frequently asked questions

Is Convex down right now?

Check the board above; it reflects our own probes against Convex's platform API from all five of our regions, refreshed every couple of minutes. Your deployment has its own hostname, so this is a platform-level signal rather than a reading of your project.

My Convex queries stopped updating in the browser. Is that an outage?

Check the client's websocket connection before assuming so. Convex pushes updates over a persistent connection, and a connection that dropped without reconnecting produces a UI frozen on stale data while the backend is entirely healthy. A page refresh re-establishes it, which is a quick way to tell a client problem from a platform one.

Why did my mutation fail with a conflict?

Because Convex runs mutations as serializable transactions and will reject one that conflicts with another rather than letting both commit an inconsistent result. Client libraries retry these automatically in most cases, so seeing them frequently in logs points at contention, usually several users writing the same document, rather than at instability in the platform.

Does a Convex incident affect my scheduled functions and cron jobs?

It can, and they are worth checking separately after any incident. Scheduled work runs on the platform rather than in a browser, so a period of unavailability can delay or skip runs that your application assumed had happened. The functions log in the Convex dashboard shows what actually executed, which is where to confirm rather than assume.

How is this page different from Convex's own status page?

Theirs reports what Convex's engineers have confirmed and chosen to publish. This page reports what our probes measured from outside their infrastructure, on a fixed schedule, whether or not an update has been written. Neither one alone tells the whole story during an incident, so checking both is worth the extra minute.