Monitor an Experiment

Statsig runs health checks on every live experiment: SDK checks arriving, unit IDs matching, exposures balanced with no sample ratio mismatch (SRM), and no crossover units. Review the checks after you launch the experiment and again before you read its results. Use this page to find out whether assignment and logging are correct. To interpret metric lifts, go to How to read experiment results. To clone, rename, archive, or otherwise operate on the experiment itself, go to Manage an Experiment.

Experiment health checks

1. Go to Experimentation > Experiments and select the experiment you want to inspect.
2. In the Details panel, find the health status badge next to the quality score, for example Healthy or Unhealthy.
3. Hover over the badge to see the Experiment Health Check summary, then click View Details.

Alternately, open the Diagnostics tab, which leads with the Experiment Health Check section. A warning icon on the Diagnostics tab label also signals a failing check. Select a check to read its status, such as FAILED, and an explanation of what triggered it.

The checks shown depend on the experiment's setup and how long it's been running. The console organizes each check by its current state. For example: Checks not yet detected or Pulse metrics available. Common health checks include:

• Checks detected: Verifies that the SDK is reporting config checks shortly after launch. Checks not detected recently means the experiment previously recorded exposures but none in the last 24 hours.
• Valid unit type: Confirms that checks include the experiment's configured ID type.
• Event metrics have data: Ensures that events carry the same unit ID as exposures. This lets Statsig compute metrics. This check often surfaces problems when downstream tooling, such as Segment, omits stableID or custom IDs.
• Pulse metrics available: Indicates that results are ready (typically the day after launch).
• Exposures are balanced: Runs a chi-squared test for sample ratio mismatch (SRM). Occasionally, warnings occur because of randomness, but persistent red alerts point to assignment or logging issues. Refer to SRM thresholds for more information.
• Crossover units detected: Highlights units exposed to more than one group, when they exceed 0.1% of exposed units. Statsig Cloud keeps these units in both groups because the SDK rarely produces crossovers, and flags them so you can address the root cause. Refer to Crossover troubleshooting.
• Default value type mismatch: Warns if an experiment's fallback default value type disagrees with the parameter definition.
• Group Assignment Health: Surfaces unexpected assignment reasons (for example, Uninitialized or InvalidBootstrap). Click View Assignment Reasons to see the hourly breakdown.
• Differential Impact Detection: Reports when Statsig has finished checking whether a group of users responds to the treatment differently from the rest. Refer to Differential impact detection.

SRM thresholds

The Exposures are balanced check sets its status from the chi-squared p-value and the absolute deviation from the expected split.

To diagnose and resolve SRM, go to Managing SRM.

Guardrail metric alerts

The Diagnostics tab lists the metric alerts attached to this experiment under Guardrail Metric Alerts. It displays each metric's current status and when it last triggered. When an alert generates, a banner appears at the top of the experiment and a matching card appears on the Results tab. Select Resolve to clear an alert and record why.

For more information, go to Rollout alerts, which covers how to create an alert as well as how Statsig evaluates your alerts.

Crossover troubleshooting

A crossover unit is a unit that logged exposures to more than one group of the same experiment run. Statsig can't attribute that unit's behavior to a single variant. The Crossover units detected check appears when crossover units exceed 0.1% of exposed units.

How Statsig Cloud handles crossover units

Statsig Cloud keeps a crossover unit in both groups instead of discarding it. Statsig SDKs produce crossovers rarely, and the units that do cross over tend to cross in every group rather than in one. Including them dilutes the measured effect slightly instead of biasing it toward one group.

Below 1%, treat the check as a prompt to find the root cause, not as a reason to discard the readout. Above 1%, contact Statsig in Slack: a rate that high usually points to an implementation problem.

Warehouse Native drops crossover units from the analysis instead of keeping them, because it often reads exposures from another assignment service where crossover rates run higher. For that behavior and its thresholds, go to Monitor an experiment in the Warehouse Native documentation.

Common causes of crossover units

What doesn't count as crossover

Two patterns look like crossover in the exposure stream, but neither triggers the check:

Prevent crossover with persistent assignment

Configure persistent assignment on a supported server SDK before you start the experiment. Persistent assignment saves each unit's evaluation the first time the SDK evaluates it, then loads that saved evaluation on later calls. The unit keeps its group even when the experiment's configuration changes, which is the only way to keep an assignment stable through a configuration change.

If you can't pinpoint the cause, contact Statsig in Slack for help.

Exposure streams

The Exposure Stream section on the Diagnostics tab lists the most recent exposures for the experiment. Use it to confirm that checks arrive, that targeting resolves the way you expect, and that your SDKs evaluate against current configuration. Select Show non-production logs to include checks from non-production environments.

Read an exposure row

Eval Time moves only when an SDK picks up a configuration change, so the gap between it and Received widens the longer a project goes without one. Don't read that gap as delivery latency: neither column reports how long Statsig took to ingest the exposure. To measure SDK upload latency, turn on SDK debug logging instead.

Query the stream

The Query Exposures panel beside the table controls what the stream returns. Choose a time range, select + next to Filters to filter on a column or user property, then select Apply.

The time range reaches back 7 days at most. Calendar days older than that aren't selectable, and presets wider than 7 days don't appear. This limit applies to row-level exposure queries in the console for every project, and no setting extends it. It bounds the query, not your data.

What the exposure stream can't tell you

Each query returns at most 100 rows, newest first, however wide the time range. Treat the stream as a recent sample for debugging rather than an export. It also lists every evaluation that reached Statsig, including rows that bot filtering later removes, so it isn't the analyzed population. A row missing here is weaker evidence than a unit missing from your results.

For exposure counts over a longer window, select View in Metrics Explorer in the Exposure Stream header. That view aggregates exposures and the 7-day limit doesn't apply to it.

Cumulative exposures

To track growth per variant:

1. Open the Results tab.
2. Find the Cumulative Exposures card below the hypothesis. It shows the total exposures and each group's share.
3. Click See More to expand the chart.

The chart shows how many units entered each group over time, so you can identify ramp issues early. A band that flattens means the experiment stopped assigning units, and a band that outpaces the others points at an uneven split.