Statsig Release Notes

🔐 Self-Serve RBAC for the Statsig MCP

You can now manage MCP access directly in the console, with project-level and role-level controls.

What you can do now

• Set a project-level MCP scope — No access, Read only, or Read and write — as the ceiling for all roles in that project.
• Configure MCP access per role within that project maximum, including Member and custom roles.
• MCP only exposes tools that the project scope, role permissions, and token scope all allow.

To configure:

Go to Project Settings > Roles to set Default Project MCP Scope, then open a role's Permissions > MCP to configure its access.

Why this matters

Before this, teams that wanted to give analysts or stakeholders AI-assisted exploration through the MCP had no way to cap what they could do. Now, you can give some users read-only MCP access for exploration while keeping write access to the people who need it.

Try it out

Go to Project Settings > Roles in the Statsig console to configure MCP access for your team.

Learn more in the Statsig MCP Overview.

Role permissions now let you control edit and delete access separately for each config type.

What you can do now

Each role can now be configured with independent edit and delete permissions for:

Gates · Holdouts · Dynamic Configs · Segments Experiments · Layers · Autotunes · Parameter Stores · Prompts

Why this matters

Before this, permissioning wasn't specific and allowed for broad experiment and gates access. Now, you can define roles that match how your teams actually own and operate different config types, without over-permissioning anyone.

Try it out

Available now for all Enterprise customers. Go to Settings in the Statsig console to configure granular permissions per role.

Learn more in the

Statsig Access Management docs
.

Create_Experiment and Update_Experiment_Entirely now accept five additional fields, giving you fuller control over experiment setup through the MCP.

What you can do now

Five new fields are now accepted by Create_Experiment and Update_Experiment_Entirely :

secondaryIDType identifierMappingMode enabledNonProdEnvironments links secondaryMetrics

Why this matters

Now, you can set secondary ID types, identifier mapping, non-prod environments, secondary metrics, and external links without falling back to the console.

Try it out

If you have the Statsig MCP set up, try a prompt like:

"Using the Statsig MCP, create an experiment with a secondary metric of revenue and enable it in staging."

Learn more in the Statsig MCP Overview.

You can now map your identity provider's role names to Statsig roles without renaming anything in your IdP.

What you can do now

• Create aliases on the Statsig side that translate your IdP's existing role names to first-class Statsig roles. Works with Okta, Microsoft Entra ID, and other SCIM-compatible identity providers with strict or unchangeable naming conventions.
• Self-serve setup in a few clicks. No support ticket or manual intervention needed

Why this matters

Now, SCIM provisioning no longer requires your IdP group names to match an expected role format. You can define the translation on the Statsig side and let provisioning work with whatever names your IdP already uses.

Try it out

Go to Settings in the Statsig console to configure SCIM role aliases for your organization.
Learn more in the Statsig SCIM docs.

New Athena Warehouse Native projects now get the Pipeline Overview dashboard set up automatically on connection creation.

What you can do now

• Get the Pipeline Overview dashboard, metric source, and pipeline table created automatically when setting up a new Athena connection
• No manual repair or setup step needed to get DAG and pipeline visibility from day one

Why this matters

Before this, new Athena projects skipped the Pipeline Overview provisioning step entirely, leaving teams with no pipeline observability until someone ran a manual repair. Now, you get full pipeline visibility out of the box from the moment your connection is created.

Try it out

Create a new Athena Warehouse Native connection in the Statsig console to see the Pipeline Overview dashboard provisioned automatically.
Learn more in the Statsig Warehouse Native docs.

You can now pull the data behind the Daily Checks column in the experiment list directly over the API.

What you can do now

One new endpoint is available on statsigapi.net/console/v1/ :

GET /console/v1/experiments/{id}/diagnostics_checks?lastDays=30

• Use lastDays (1-90) to set a lookback window without computing dates yourself
• Use startDate / endDate if you need an explicit range instead
• is_realtime tells you whether the final day is still filling, so you know not to treat it as a complete day
• Warehouse Native experiments now return real data from the warehouse exposures summary, the same source the console list column uses

Why this matters

Before, the Daily Checks column in the experiment list flagged experiments that were "In Progress" after being pulled from code, or "Decision Made" while still serving traffic and catching those states meant querying your own warehouse. Now, you can surface that signal programmatically and build automated checks or alerts on top of it.

Try it out

Review the full API reference in the Statsig Console API docs.

💰 Warehouse Native Query Cost Attribution

Statsig WHN queries now carry cost attribution tags in your warehouse, so you can see exactly what Statsig activity is driving your compute costs.

What you can do now

Every query is stamped with is_whn, a type (experiment, gate, etc.), the experiment or gate name, a job type, and the reload ID. Tags land natively in each warehouse — nothing leaves your account:

• Snowflake — session QUERY_TAG in ACCOUNT_USAGE.QUERY_HISTORY and QUERY_ATTRIBUTION_HISTORY
• BigQuery — job labels (type=whn_query) in INFORMATION_SCHEMA.JOBS
• Redshift — query_group in SYS_QUERY_HISTORY.query_label
• Databricks — statement comment in system.query.history

Why this matters

Before , you could see total spend but had no way to attribute it to a specific experiment or job type in Statsig. Now, you can point one query at your warehouse's usage view, filter to Statsig WHN queries, group by experiment, and get per-experiment reload cost, making it straightforward to spot expensive reloads and change your schedule.

Try it out

Filter your warehouse usage view to is_whn:"True" (or type=whn_query on BigQuery) and group by experiment to see per-experiment reload costs.

Learn more in the Statsig Warehouse Native docs.

Setting up Layers when creating an experiment is now easier than ever.

What you can do now

• See Layers as a top-level Targeting option alongside ID Type and Target Applications.
• Pick a layer and have ID Type and Target Applications auto-fill and lock automatically.
• Clear the layer to unlock those fields and keep your values.
• See Target Applications displayed by name rather than a raw count

Why this matters

Layers keep experiments mutually exclusive, preventing cross-experiment contamination across your project. With Layers now a top-level option in the Create Experiment modal, setting them up correctly takes less effort from the start.

Try it out

Open the Statsig console and create a new experiment to try it out.

View and manage values entered into freeform or custom-value fields when editing targeting rules, however many you want.

What you can do now

A new and improved StatsigValueMultiSelect component gives you:

• A dropdown that makes the complete list easy to view and manage, including removing individual values
• A dedicated input for adding or pasting values
• Search across both added values and available autocomplete suggestions
• Selected-value chips with an accurate +N more summary that includes only values not already visible
• Clear sections separating search results and added values
• A contextual empty state when no values have been added
• Type-aware copy throughout, e.g. “Add or search Unit IDs,” “Added Unit IDs,” and “No Unit IDs added”
• Copy-all and remove-all actions

It can be reused across targeting rules and other custom-value workflows. Preset-only selectors such as Operating System and Device remain unchanged and will be updated to have a more consistent UI.

Why this matters

Previously, the targeting input displayed only a few values and hid the rest behind a popover, making values increasingly difficult to find and remove as lists grew. Adding new values was also cumbersome through the existing input field, and there was no way to search existing values.

If you have lots of values to add, that's easier now.

Try it out

This is currently behind a feature gate, but will be released to all customers soon. If you want early access, reach out to your account team.

You can now give gates, experiments, and dynamic configs the same display name.

What you can do now

• Use duplicate display names across feature gates, experiments, dynamic configs, and their templates.
• When a name collision occurs, the ID auto-resolves to the smallest free suffix (checkout_flow becomes checkout_flow_1) and Create stays enabled with an info note instead of a dead-end error.
• Edit the auto-generated ID inline by hovering or focusing the row and clicking the pencil icon.
• Works across create, clone, and rename flows.

Why this matters

Before this, two entities with the same display name hit "ID already in use" and teams with naturally similar naming conventions had to add arbitrary suffixes just to get past the create step. Now display names can reflect what something actually is, while uniqueness is still enforced on the ID.

Try it out

Open the Statsig console and create a new gate, experiment, or dynamic config with a name that already exists to see the new flow in action.

Reorder+ Insight Targeting Rules

Managing targeting rule order is now faster and more intuitive.

What you can do now

• Drag any rule by its IF / ELSE IF rail to reorder it inline — no more opening a separate Reorder Rules modal.
• Hover on any rule to reveal an "Insert new rule" button and drop a new rule exactly where you want it, instead of adding to the bottom and dragging it up.
• Precedence labels update live as you drag so you always know where a rule will land

Why this matters

Rule order matters in targeting. Before this, reordering required a separate modal. Now, you can build and adjust targeting logic directly in the editor without breaking your flow.

Try it out

Open any feature gate, experiment, or dynamic config in the Statsig console and try dragging or inserting a targeting rule.

You can now remove an individual user from a Feature Gate override without touching the rest of the list.

What you can do now

One new endpoint is available on statsigapi.net/console/v1/ :

DELETE /console/v1/gates/{gateName}/overrides/userID/{userID}

Why this matters

Before this, removing a single user override meant fetching the full override list, mutating it locally, and re-posting it, which could be risky when test runs are happening concurrently. Now, you can target and remove exactly one user, leaving every other override untouched.

Try it out

Review the full API reference in the Statsig Console API docs.

Statsig Topline Alerts can now page PagerDuty directly.

What you can do now

• Add PagerDuty services to the Integrations catalog once with a name and Events API v2 routing key.
• Select one or more PagerDuty services per alert in the Notifications settings.
• Test your wiring end-to-end before you rely on it — test pages are tagged [TEST] and never collide with real incidents.
• Deleting a PagerDuty service that an alert still references is blocked, and disabled integrations are clearly flagged.

Why this matters

Topline Alerts catch anomalies in your most critical product metrics, but a notification that in Slack or email isn't always enough when something is on fire. Now, the same alert that fires in Statsig can page your on-call team in PagerDuty, closing the gap between detecting a problem and fixing it quickly.

Try it out

Go to Integrations in the Statsig console, add your PagerDuty service, then open any Topline Alert and configure PagerDuty under Notifications.
Learn more in the Statsig Topline Alerts docs.

✅ Autotune Reviews via Console, Console API, and MCP

You can now submit Autotune changes for review and manage the full review lifecycle across the console, Console API, and MCP.

What you can do now

• Submit Autotune configuration changes for review before they reach production.
• Approve, reject, or cancel in-flight Autotune reviews from the console, via CAPI, or through the MCP.
• Teams with reviews required can now enforce that same approval workflow on Autotunes, the same way they do for gates and experiments.

Why this matters

Teams running Autotune for high-stakes decisions need the same guardrails they have everywhere else. Any change to a live Autotune can shift traffic allocation immediately, so being able to require an approval before it goes out matters. Reviews are now consistent across gates, experiments, and Autotunes.

Try it out

If you have the Statsig MCP set up, try a prompt like:

"Using the Statsig MCP, open a review to update the winner threshold on autotune_name and submit it for approval."

Learn more in the Statsig Reviews docs.

🔧 Holdouts Now Accepts Public Gate IDs

PATCH /console/v1/holdouts/{id} now resolves public gate IDs for targetingGateID, the same way gateIDs and experimentIDs already do.

What you can do now

• Set targetingGateID to a public gate ID — the slug CAPI returns as id on all write paths — without hitting a 500.
• Internal IDs still work, so existing GET-edit-PUT round-trips are unchanged.
• An unknown gate now returns a clean 400 instead of a 500 null still keeps the existing gate, "" still clears it.

Why this matters

Now, targetingGateID behaves consistently with the rest of the PATCH endpoint.

Try it out

Review the full API reference in the Statsig Holdouts Console API docs.