outages.live
Live
PostHogMaintenance ·

Scheduled Ingestion Systems Maintenance -- Production EU

MaintenanceOfficial update

Maintenance has started

The latest update from PostHog.

State

Maintenance in progress

Started

Ongoing for

1 h 29 min

Worst impact

Maintenance

Timeline

2 updates
23:0323:2523:4800:1000:32
MaintenanceUpdate postedTimes in UTC

Maintenance scheduled

3 min 4%

Maintenance in progress

1 h 26 min 96%

Updates

Times in UTC

As posted by PostHog

Maintenance in progress

Maintenance has started

Maintenance scheduled

The ingestion team is performing some scheduled maintenance tasks on their system that will require consumers to be down. No data loss is expected over this maintenance window, but ingestion lag will build.

Affected components

1
Event Ingestion Lag

PostHog in the last 90 days

Full history
90 days agoToday

Incidents in 90 days

29

Days with an incident

22

Median duration

1 h 15 min

This incident

Not comparable

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

27 h 36 min
median 1 h 15 min
90 days agoToday

Other PostHog incidents

All incidents

PostHog·Event ingestion: processing delays

PostHog event ingestion had processing delays in the Event Ingestion Lag component. PostHog reports that the incident is resolved. The outage lasted about 43 minutes.

Resolved

PostHog·Workflows Email Metric Ingestion Outage

PostHog reported an ingestion problem with email metrics such as open rates, click through, and bounces. The problem started on 3 November 2026 at 11:21 UTC and lasted 244 minutes. PostHog resolved the incident at 15:25 UTC.

Resolved

PostHog·Agents: elevated GitHub error rates

We’ve deployed a mitigation for transient GitHub errors and haven’t observed further failures since.

Resolved

PostHog·Application: partial outage

All services have returned to normal.

Resolved

PostHog·PostHog AI connections

This issue has been resolved. PostHog AI and other services are back to normal. Apologies for the interruption.

Resolved

Follow PostHog

Your coding agent knows when PostHog is down, and tells you when a failure is theirs, not yours. You can also get PostHog 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.live/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 "posthog" and tell me if PostHog 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.live/feed.xml?providers=posthog
Slack
/feed subscribe https://outages.live/feed.xml?providers=posthog

FAQ

Go from tracking outages to fixing production issues with Polylane.

Try Polylane