outages.live
Live
StatsigIncident ·

Aug 26 Incident Follow-up: Feature Gate Exposure Data Delayed for Some Warehouse-Native (WHN) Customers

ResolvedOfficial update

Full 8/25–8/27 recovery is complete. For the gates with no metrics attached, exposures for 8/25–8/27 should now be available in the warehouse!

The latest update from Statsig.

State

Resolved

Started

Lasted

3 days

Worst impact

Degraded

Timeline

2 updates
Aug 28Aug 29Aug 30Aug 30Aug 31
DegradedUpdate postedDates in UTC

Monitoring

3 days 100%

Updates

Times in UTC

As posted by Statsig

Resolved

Full 8/25–8/27 recovery is complete. For the gates with no metrics attached, exposures for 8/25–8/27 should now be available in the warehouse!

Monitoring

Follow up to the Aug 26 issue impacting Warehouse-Native (WHN) customers: https://status.statsig.com/incidents/prtl9797v2y0 We recently identified a sub-issue affecting the export of exposure data for certain Feature Gates, specifically those gates without an associated metric, with 100%/0% rollout etc where no analytics is turned on. For these Feature Gates, the exposures for August 25 onward may still be missing or incomplete in your warehouse. Experiment exposures, live event ingestion, and the Exposure Stream are unaffected. Underlying exposure data has not been lost and is being backfilled. We have identified the root cause, deployed a fix, and are actively backfilling affected data for impacted customers. No action is needed and no reload is needed. Customers can expect/monitor those gates' exposure landed into their warehouse in the next two days.

Affected components

1
Event Forwarding Pipeline (Warehouse Native)

Statsig in the last 90 days

Full history
90 days agoToday

Incidents in 90 days

2

Days with an incident

6

Median duration

37 h 25 min

This incident

1.8× the median

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

3 days
median 37 h 25 min
90 days agoToday

Other Statsig incidents

All incidents

Statsig·Warehouse Native accounts may be experiencing export delays for data from Aug 6

This incident has been resolved

Resolved

Follow Statsig

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

FAQ

Go from tracking outages to fixing production issues with Polylane.

Try Polylane