Some HTTP Actions returning 404
This incident is resolved. Between 00:20 and 04:15 UTC on 12 August, some HTTP Actions returned a 404 response. This affected requests that reached Convex through an intermediate proxy or CDN, because those requests carry an `X-Forwarded-Host` header. A change to our edge configuration made it read that header instead of the request's own hostname, so it looked for the wrong deployment. We reverted the change in all regions and error rates are back to their normal level. No data was lost, and requests that did not carry that header were unaffected. We are sorry for the disruption, and are improving our testing and monitoring of edge configuration changes to catch issues like this before they reach production.
The latest update from Convex.
State
Resolved
Started
81 d ago
2026-08-12 03:41 UTC
Lasted
20 min
until 2026-08-12 04:01 UTC
Worst impact
Degraded
Timeline
2 updatesIdentified
20 min 100%
Updates
Times in UTCAs posted by Convex
This incident is resolved. Between 00:20 and 04:15 UTC on 12 August, some HTTP Actions returned a 404 response. This affected requests that reached Convex through an intermediate proxy or CDN, because those requests carry an `X-Forwarded-Host` header. A change to our edge configuration made it read that header instead of the request's own hostname, so it looked for the wrong deployment. We reverted the change in all regions and error rates are back to their normal level. No data was lost, and requests that did not carry that header were unaffected. We are sorry for the disruption, and are improving our testing and monitoring of edge configuration changes to catch issues like this before they reach production.
We're investigating reports that HTTP Actions are returning 404 responses when an `X-Forwarded-Host` header is set on the incoming request. We've identified a potential infrastructure change and are reverting it now.
Affected components
6Convex in the last 90 days
Full historyIncidents in 90 days
7
Days with an incident
9
Median duration
54 min
This incident
63% shorter than the median
Other Convex incidents
All incidentsConvex·Elevated Error Rate for Deploying Node Actions
This issue is resolved, we are continuing to monitor.
Convex·Failing function calls
On 2026-10-09, between 22:11 and 22:52 UTC, some query and mutation executions running in us-east-1 failed to run. This outage was caused by a network issue at an upstream provider. The problem is now resolved.
Convex·AI gateway unavailable
An issue with an upstream provider caused requests to the AI Gateway to be rejected. The issue has been resolved and service has been restored. We apologize for the disruption.
Convex·Dashboard logins degraded
This incident has been resolved.
Convex·Account verification/team invite emails not working
This incident has been resolved.
Follow Convex
Your coding agent knows when Convex is down, and tells you when a failure is theirs, not yours. You can also get Convex incidents in a feed reader or in Slack.
Install the outages.live MCP server, so that when something breaks you can tell if the cause is a provider we depend on and not my code. It reads the official status pages of cloud, AI, payment and developer providers and gives you their incidents as MCP tools.
Add it as a remote MCP server named "outages" at https://outages.cc/mcp (Streamable HTTP, no authentication), with your CLI command or your MCP config file.
Then:
1. Make sure it connects and shows the tools get_provider, list_feed and send_feedback.
2. Call get_provider with "convex" and tell me if Convex has a problem right now.
3. From now on, when a call to a third-party service fails or becomes slow, call get_provider for that service before you change my code.Paste this into any coding agent. It adds the server with its own MCP setup.
https://outages.cc/feed.xml?providers=convex/feed subscribe https://outages.cc/feed.xml?providers=convexFAQ
Go from tracking outages to fixing production issues with Polylane.
Try Polylane