Scheduled Reloads

How scheduled reloads work

Scheduled reloads refresh the data behind your Metrics and Experiments from your warehouse on a daily cadence. Control these reload settings on each entity, or set project-level defaults that entities inherit from in your Project Settings. You can also use the Console API to trigger experiment result loads. The Console API is useful for triggering refreshes when your data pipelines are ready.

Reload schedules and exposure forwarding

Scheduled reloads refresh experiment results. They may also forward recent exposures before the daily export, but these updates are best-effort and can be incomplete.

The daily exposure export runs separately from results reloads and is the authoritative record of eligible forwarded exposures. Changing the reload schedule doesn't change forwarding eligibility or backfill the forwarded exposures table. For details, go to Forwarded Data.

Gate/experiment Pulse scheduling

For feature gates and experiments, you can configure individual Pulse scheduling separately from the project-level settings. Schedule daily Pulse metric reloads for individual feature gates and experiments.

To access this feature:

1. Navigate to your feature gate/experiment in the Statsig Console
2. Go to the Pulse Results tab
3. Use the scheduling controls to configure daily reloads

The scheduling allows you to:

• Set a daily reload time in UTC
• Choose between Full and Incremental reload types
• Save, edit, or cancel scheduled reloads

Individual Pulse scheduling requires gates with partial rollout rules and overrides project-level settings.

Review scheduled reloads across the project

Settings > Data Connection > Reload Settings has a Scheduled Reloads section that lists the experiments and feature gates carrying a reload schedule in one table, instead of making you open each entity's Pulse Results tab. Use it to find the hours your reloads cluster into and to move entities off a crowded slot. Spreading start times keeps the pipeline from firing a burst of concurrent queries at your warehouse.

A Type column marks each row as an experiment or a gate. Experiments that inherit the project-default schedule appear alongside entities with their own schedule, and the duration column fills in for experiments only. Gate rows link out to that gate's diagnostics.

To change a schedule from the table:

1. Go to Settings > Data Connection > Reload Settings.
2. Find the entity in the Scheduled Reloads table.
3. Click Edit on that row. The Edit Scheduled Reloads modal opens with the entity's current settings.
4. Adjust the schedule, then save.

Edit one entity at a time. The table has no multi-select or bulk schedule change.

Edit is unavailable when you lack permission to change the entity, when a review is in progress for it, or when creation validation is still pending. The button's tooltip names the reason.

What the table includes

An entity appears in Scheduled Reloads when it has a schedule and meets its type's conditions:

• Experiments: in progress, not archived, and passing the Warehouse Native reload lifecycle checks.
• Feature gates: enabled, not archived, and running a partial rollout.

Everything else stays out, so treat the table as a view of active schedules rather than a complete inventory of the project:

• Experiments that are unstarted or in draft, stopped, ended, launched, decided, abandoned, or archived.
• Feature gates that are disabled, archived, or fully rolled out.
• Dynamic configs, metrics, and holdouts, none of which ever appear.

Editing a schedule here changes when the scheduler starts an entity's reload. It doesn't change how the scheduler runs that reload.