Is Confluent Down?

No — Confluent is up

Reachable from all 8 checked regions

Average response time: 112ms

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

236ms

Avg response, 30 days

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

30-day history

25-day clean streak

Aug 12 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

66ms

DNS 0ms TCP 2ms TLS 21ms TTFB 39ms

lhr

42ms

DNS 1ms TCP 2ms TLS 15ms TTFB 26ms

nrt

346ms

DNS 1ms TCP 1ms TLS 10ms TTFB 208ms

ord

80ms

DNS 0ms TCP 1ms TLS 26ms TTFB 42ms

sin

57ms

DNS 0ms TCP 3ms TLS 12ms TTFB 33ms

sjc

39ms

DNS 5ms TCP 1ms TLS 10ms TTFB 22ms

syd

27ms

DNS 0ms TCP 1ms TLS 8ms TTFB 16ms

yyz

242ms

DNS 0ms TCP 11ms TLS 25ms TTFB 130ms

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 18 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 18 cities across three regions, and tell you the moment something breaks.

Start Free Monitoring

Free plan available No credit card required