Is Confluent Down?

No — Confluent is up

Reachable from all 8 checked regions

Average response time: 272ms

Last checked 3 hours ago · checks run every 6 hours

Official status page: https://status.confluent.cloud

Confluent uptime

100%

Last 7 days

100%

Last 30 days

100%

Last 90 days

408ms

Avg response, 30 days

Measured from multiple regions every 6 hours. Percentages count only checks that returned an availability answer — 58 days measured so far. A dash means that window does not yet hold enough measured days to publish a figure.

30-day history

58-day clean streak

Sep 14 Today

No downtime Partial Downtime Not measurable No data

Reachability by region

Each region runs its own request from a different part of the world. A service can be up for one continent and down for another, which is usually the first sign of a routing or CDN problem.

ams

260ms

DNS 181ms TCP 8ms TLS 22ms TTFB 229ms

arn

385ms

DNS 201ms TCP 1ms TLS 56ms TTFB 289ms

cdg

130ms

DNS 39ms TCP 9ms TLS 27ms TTFB 96ms

dfw

288ms

DNS 105ms TCP 25ms TLS 29ms TTFB 189ms

ewr

313ms

DNS 247ms TCP 1ms TLS 22ms TTFB 285ms

fra

167ms

DNS 132ms TCP 1ms TLS 13ms TTFB 159ms

syd

324ms

DNS 299ms TCP 1ms TLS 10ms TTFB 317ms

yyz

311ms

DNS 95ms TCP 12ms TLS 28ms TTFB 259ms

What Confluent does

Confluent sells managed Apache Kafka: hosted brokers, schema registry, connectors and stream processing, used as the backbone that moves events between services. When it stops, the applications either side often stay up and simply stop hearing from each other. Confluent Cloud itself refuses automated probes, so this page measures Confluent's public site rather than the cluster endpoints your producers connect to.

What an outage looks like

Producers fail to acknowledge writes and buffer locally until they run out of memory. Consumers stop advancing and consumer lag climbs steadily on dashboards. Schema Registry lookups fail, so applications that validate messages on startup refuse to start even where brokers are healthy. Managed connectors stall, leaving sinks such as warehouses and search indexes progressively further behind the source.

What to do about it

Check status.confluent.cloud, which reports Confluent Cloud components and posts incident updates by email, Slack, webhook or feed. Kafka retains messages, so a broker incident is usually a delay rather than data loss: let producers retry with backoff instead of dropping messages. Watch consumer lag as service returns, because a large backlog can overwhelm downstream systems when consumption resumes.

Is it down for everyone, or just you?

If this page says Confluent is up but it is not loading for you, the problem is between you and them. Run a check against any URL from up to 17 cities across three regions to find out where it breaks.

Test it yourself

Related services

MongoDB Atlas

Snowflake

AWS

Datadog

Confluent outage FAQ

Will I lose events during a Confluent outage?

Usually not, because Kafka is built around retention. Messages already committed to a topic stay there for the configured retention period and consumers pick up from their last offset when they reconnect. The genuine loss risk sits on the producer side: an application that cannot write and does not retry or buffer will discard events, so producer retry configuration decides the outcome.

Consumer lag is climbing. Is that the outage or my consumers?

Rising lag on its own means consumption is slower than production, which an incident causes but so does a slow or crash-looping consumer. Check whether the consumer group is connected at all: a group with no active members points at your application, while connected members making no progress points upstream. Confluent's status page settles it either way.

Does a Confluent outage break my whole pipeline?

It breaks the movement, not usually the endpoints. Services that produce and consume events tend to keep serving their own traffic while the stream between them stops, so the visible effect is staleness rather than errors: a search index that stops updating, a warehouse missing recent rows, a downstream service acting on old state. Managed connectors resume once brokers recover.

Why do my applications fail to start when the brokers look fine?

Schema Registry is a separate component from the brokers and it fails separately. Applications that fetch and validate schemas during startup cannot initialise when the registry is unavailable, even though the brokers are accepting traffic normally. Already-running instances usually carry on with cached schemas, which is why a rolling deploy during a registry incident is worse than waiting.

How we measure this

We request Confluent's public endpoint every 6 hours from Fly.io regions across six continents — the most recent check ran from 8 of them.
A region counts as down only when it gets no usable HTTP response. A 403 or 429 means the origin answered and refused us, which we report as blocked, never as an outage.
A single failing region is treated as probe noise. We only change the verdict when two consecutive cycles agree.
Response times average only the regions that actually served the page, so a timeout never inflates the number.
Where Confluent publishes an official status feed we read it too. An all-clear from the vendor can soften an unconfirmed degradation; a vendor-declared outage only worsens our verdict when our own checks corroborate it.

Get alerted when Confluent goes down

This page refreshes every 6 hours. Your own monitors run as often as every 30 seconds, from up to 17 cities across three regions, and tell you the moment something breaks.

Start Free Monitoring

Free plan available No credit card required