Live

ClickPipes failing on Kinesis in AWS us-east-1

This incident has been resolved. AWS has confirmed that the Enhanced Fanhout (EFO) Kinesis pipes in us-east-1 region are fully operational. Please contact ClickHouse Support if you experience any further issues:

The latest update from ClickHouse Cloud.

State

Resolved

Started

47 d ago

2026-09-15 18:57 UTC

Lasted

29 h 46 min

until 2026-09-17 00:43 UTC

Worst impact

Degraded

Timeline

6 updates
18:5702:2409:5017:1600:43
DegradedUpdate postedTimes in UTC

Investigating

1 h 6 min 4%

Identified

28 h 40 min 96%

Updates

Times in UTC

As posted by ClickHouse Cloud

Resolved2026-09-17 00:43 UTC

This incident has been resolved. AWS has confirmed that the Enhanced Fanhout (EFO) Kinesis pipes in us-east-1 region are fully operational. Please contact ClickHouse Support if you experience any further issues:

Identified2026-09-16 15:21 UTC

AWS has confirmed that on September 15, 2026, beginning at 11:15 AM PDT, customers experienced elevated AccessDeniedException errors when calling the RegisterStreamConsumer API for Amazon Kinesis Data Streams (Kinesis) in the N. Virginia (us-east-1) Region. The root cause was a recent change that introduced a defect in how RegisterStreamConsumer requests are authorized, causing each request to be evaluated against the specific consumer resource (for example, `arn:aws:kinesis: : :stream/ /consumer/ `) rather than the stream resource (for example, `arn:aws:kinesis: : :stream/ `). As a result, IAM policies that granted kinesis:RegisterStreamConsumer only at the stream level, which previously succeeded and aligns with our published documentation, no longer matched the request and returned AccessDeniedException. AWS has begun rolling back this change in the affected Region, and expect calls that were previously permitted at the stream level to succeed again once the rollback completes on Se

Identified2026-09-16 03:17 UTC

AWS has confirmed that on September 15, 2026, beginning at 11:15 AM PDT, customers experienced elevated AccessDeniedException errors when calling the RegisterStreamConsumer API for Amazon Kinesis Data Streams (Kinesis) in the N. Virginia (us-east-1) Region. The root cause was a recent change that introduced a defect in how RegisterStreamConsumer requests are authorized, causing each request to be evaluated against the specific consumer resource (for example, `arn:aws:kinesis: : :stream/ /consumer/ `) rather than the stream resource (for example, `arn:aws:kinesis: : :stream/ `). As a result, IAM policies that granted kinesis:RegisterStreamConsumer only at the stream level, which previously succeeded and aligns with our published documentation, no longer matched the request and returned AccessDeniedException. AWS has begun rolling back this change in the affected Region, and expect calls that were previously permitted at the stream level to succeed again once the rollback completes on Se

Identified2026-09-15 22:45 UTC

AWS has confirmed the issue on their end and are in the process of rolling back the change. The ETA for this rollback in us-east-1 is by end of day tomorrow. Signs of gradual recovery are expected in us-east-1 as the rollback progresses across AZs during this time. In the meantime, if your ClickPipe is still affected, please update your IAM policy as instructed in the previous status update.

Identified2026-09-15 20:03 UTC

The issue has been identified as a change on AWS related to Kinesis IAM permissions and appears to be currently isolated to us-east-1. While we work with AWS to mitigate this issue, we recommend to update your IAM policy to include a trailing wildcard (`/*`) to the resource for the `kinesis:RegisterStreamConsumer` action like so: ``` { "Effect": "Allow", "Action": [ "kinesis:RegisterStreamConsumer" ], "Resource": [ "arn:aws:kinesis:{REGION}:{ACCOUNT_ID}:stream/{STREAM_NAME}/*" ] } ``` Once this is applied, you must restart your ClickPipe for the changes to take affect.

Investigating2026-09-15 18:57 UTC

Currently investigating failures on AWS us-east-1 for customers using ClickPipes on Kinesis in this region.

ClickHouse Cloud in the last 90 days

Full history
90 days agoToday

Incidents in 90 days

14

Days with an incident

14

Median duration

1 h 14 min

This incident

24× the median

How long each incident lasted, on the day it started. The outlined bar is this incident.

29 h 46 min
median 1 h 14 min
90 days agoToday

Other ClickHouse Cloud incidents

All incidents

Follow ClickHouse Cloud

Your coding agent knows when ClickHouse Cloud is down, and tells you when a failure is theirs, not yours. You can also get ClickHouse Cloud incidents in a feed reader or in Slack.

Prompt
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 "clickhouse" and tell me if ClickHouse Cloud 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.

RSS
https://outages.cc/feed.xml?providers=clickhouse
Slack
/feed subscribe https://outages.cc/feed.xml?providers=clickhouse

FAQ

Go from tracking outages to fixing production issues with Polylane.

Try Polylane