Skip to main content

Is PostHog Down?

No — PostHog is up

Reachable from all 8 checked regions

Average response time: 113ms

Last checked · checks run every 6 hours

Official status page: https://www.posthogstatus.com

PostHog uptime

100%
Last 7 days
100%
Last 30 days
100%
Last 90 days
113ms
Avg response, 30 days

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

30-day history

26-day clean streak
Jul 25: no data
Jul 26: no data
Jul 27: no data
Jul 28: no data
Jul 29: 100.00% uptime, 8 checks
Jul 30: 100.00% uptime, 32 checks
Jul 31: 100.00% uptime, 32 checks
Aug 1: 100.00% uptime, 32 checks
Aug 2: 100.00% uptime, 32 checks
Aug 3: 100.00% uptime, 24 checks
Aug 4: 100.00% uptime, 24 checks
Aug 5: 100.00% uptime, 35 checks
Aug 6: 100.00% uptime, 32 checks
Aug 7: 100.00% uptime, 32 checks
Aug 8: 100.00% uptime, 32 checks
Aug 9: 100.00% uptime, 32 checks
Aug 10: 100.00% uptime, 32 checks
Aug 11: 100.00% uptime, 32 checks
Aug 12: 100.00% uptime, 32 checks
Aug 13: 100.00% uptime, 40 checks
Aug 14: 100.00% uptime, 32 checks
Aug 15: 100.00% uptime, 40 checks
Aug 16: 100.00% uptime, 32 checks
Aug 17: 100.00% uptime, 32 checks
Aug 18: 100.00% uptime, 32 checks
Aug 19: 100.00% uptime, 32 checks
Aug 20: 100.00% uptime, 32 checks
Aug 21: 100.00% uptime, 31 checks
Aug 22: 100.00% uptime, 32 checks
Aug 23: 100.00% uptime, 32 checks
Jul 25 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.

gru
101ms
DNS 0ms TCP 3ms TLS 10ms TTFB 56ms
iad
105ms
DNS 0ms TCP 2ms TLS 5ms TTFB 39ms
jnb
240ms
DNS 0ms TCP 1ms TLS 62ms TTFB 130ms
lax
104ms
DNS 0ms TCP 1ms TLS 26ms TTFB 63ms
lhr
87ms
DNS 0ms TCP 0ms TLS 7ms TTFB 72ms
nrt
63ms
DNS 0ms TCP 2ms TLS 8ms TTFB 43ms
ord
179ms
DNS 0ms TCP 13ms TLS 18ms TTFB 96ms
sin
51ms
DNS 0ms TCP 2ms TLS 7ms TTFB 31ms
sjc
77ms
DNS 0ms TCP 2ms TLS 8ms TTFB 30ms

What PostHog does

PostHog is a product analytics platform combining event tracking, session replay, feature flags and experiments in one tool. Product and engineering teams use it to see how features are actually used, and because its snippet runs inside the customer's own application, the integration point sits in the browser rather than only on the server.

What an outage looks like

The PostHog web app fails to load or dashboards render without data, so charts appear flat rather than broken. Newly captured events stop appearing in live views, and session replays either do not record or cannot be played back. Because the tracking snippet runs client-side, the application being measured usually keeps working normally while its analytics quietly go blank.

What to do about it

Check posthogstatus.com, where PostHog posts incidents; status.posthog.com redirects there. Confirm the gap is in PostHog rather than in your own instrumentation before changing any tracking code, since a deploy made mid-incident is hard to untangle afterwards. Note the affected window so that later analysis does not read missing data as a genuine drop in user activity.

Is it down for everyone, or just you?

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

Test it yourself

Related services

PostHog outage FAQ

Is PostHog down or has my tracking broken?
Check posthogstatus.com first, because the symptoms are identical from your side. A misconfigured snippet, a blocked script and a PostHog incident all produce the same empty dashboard. If the status page reports no incident, look at your browser console for errors from the PostHog script and confirm the events are being sent at all before assuming the platform is at fault.
Does a PostHog outage break my website or app?
It should not. PostHog runs as an analytics layer alongside your application rather than in the path of a user request, so pages continue to load and features keep working while data collection fails. The exception is anything you have made dependent on PostHog at runtime, such as gating a feature on a flag, where a failure to reach the service does affect what users see.
Will I lose analytics data recorded during the outage?
Possibly, and that is the real cost of these incidents. Events that cannot reach PostHog while the browser session is open may never be delivered, since the visitor moves on and the page is gone. Record the start and end of the incident so that any later comparison accounts for the gap rather than reading it as a genuine fall in usage.
Why do my dashboards look flat rather than empty?
Because a missing event and an event that did not happen look the same on a chart. Ingestion problems show up as an unusually quiet period rather than an error, which is exactly what a real drop in traffic looks like. Cross-check against a system that does not depend on PostHog, such as your server logs or revenue numbers, before acting on a sudden decline.
Is session replay affected separately from event capture?
They can fail independently, so check what is actually degraded before investigating. Replay carries far more data than event capture and tends to be the first thing to suffer, which means replays may be missing or unplayable for a window while ordinary event data continues to arrive. Recordings that failed to upload at the time are generally not recoverable afterwards.

How we measure this

  • We request PostHog's public endpoint every 6 hours from Fly.io regions across six continents — 8 of them answered the most recent check.
  • 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 PostHog 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 PostHog goes down

This page refreshes every 6 hours. Your own monitors run as often as every 30 seconds, from the same 18 regions, and tell you the moment something breaks.

Start Free Monitoring
Free plan available No credit card required