Replicate statusLiveFetched seconds agoSource: replicatestatus.com
Is Replicate down?
Live status check · All systems operational
Live status pulled from replicatestatus.com, cached and revalidated every 60 seconds. Below: the components that can break, what to do during an incident, and how to keep your scheduled jobs running independently.
About Replicate status
Replicate is the developer-flavored serverless platform for running ML models (image, video, audio, LLM, embeddings) over plain HTTP. Incidents usually scope to the prediction API, a specific model version, or the dashboard rather than the entire platform.
Components and surfaces that can break
- Surface 01
Prediction API (POST /v1/predictions and GET /v1/predictions/:id) plus the underlying model API.
- Surface 02
Individual model versions (community-hosted models can degrade independently of Replicate-hosted official ones).
- Surface 03
Webhook event delivery and the Replicate web dashboard.
Recent Replicate incidents
Replicate maintains a public incident history. Read the latest entries to see whether you're hitting a known issue, and look at the post-mortems for context on how long similar incidents typically take to clear.
What to do if Replicate is actually down
Check whether one model is overloaded vs the platform
One popular model getting hammered (a trending image model, an LLM going viral) usually shows up as slow predictions on that single version while everything else stays healthy. Switch to a smaller or alternate version of the same model family, or wait it out.
Handle 5xx with your own backoff
Replicate retries some transient infra issues internally, but your client still sees 5xx on cold starts and capacity blips. Wrap calls in exponential backoff and treat the prediction as a job, not a request: poll the prediction ID until it completes instead of relying on a single synchronous response.
Trust webhook redelivery
Replicate retries webhook deliveries server-side, so if your endpoint was down during the prediction, the event will redeliver once you recover. Don't kick off a duplicate prediction just because the first webhook never arrived. Fetch /v1/predictions/:id first to confirm the outcome before re-running.
Keep firing through the incident
Schedule your own Replicate health check with Crontap
Scheduled inference batch jobs (nightly model runs, weekly summarization, monthly model usage rollups). Crontap fires the endpoint that calls Replicate's API, retries on 5xx and 429, and stores the prediction ID so failed jobs surface in the alert.
External HTTP cron hits your endpoint on the cadence you pick, stores every response, and emails you the moment a run fails. Pro schedules down to 1 minute; $3.25/mo annual flat for unlimited jobs.
Go deeper
Replicate status: FAQ
- Where can I see the official Replicate status?
- Replicate publishes status at status.replicate.com, which 301-redirects to the canonical page at www.replicatestatus.com. Component status covers the prediction API, the web dashboard, and webhook delivery; the history page has post-mortems and the .atom feed lets you wire incidents into your own tooling.
- Will Replicate retry my predictions during an outage?
- Partially. Replicate retries transient infrastructure failures internally so a single capacity blip doesn't kill your prediction, but it won't retry forever. Your code still needs to handle 5xx and 429 with backoff, and predictions that fail with a terminal error (model crashed, invalid input) are not retried. Treat the prediction as a job and poll the prediction ID until it resolves.
- Should I switch models during a Replicate incident?
- It depends on scope. If a single popular model version is overloaded, swap to a smaller variant of the same family and you'll usually recover. If the prediction API itself is degraded, switching models on Replicate won't help; fall back to another inference provider or pause the batch job until the status page clears.