Product Updates

🎛️ Filter Dashboards by Experiment Status

Dashboards can now focus on the experiments that are running right now.

What you can do now

• Choose Add Filter → Experiment Status on any dashboard, including dashboards generated automatically from tags

• Share the filtered view by URL, or save your selection as the dashboard’s default filter

• Experiment widgets that don’t match the filter are dimmed in place, so your layout stays intact

Why this matters

Experiment overview dashboards get cluttered as tests start and finish. Now you can keep the view focused on running experiments without removing widgets by hand.

Try it out

Open any dashboard, choose Add Filter, and select Experiment Status.

👀 Preview Changes Before Requesting a Review

You can now verify a proposed gate or dynamic config change inside the review modal before you submit it for approval.

What you can do now

• Toggle a preview with Visual and Diff views, and filter between Changes and All Rules

• See compact comparisons that highlight the changed fields when requesting a review for rule changes

• Find reviewers faster with a searchable selector for Teams and Individuals, with checkboxes and removable pills

• Get a prompt in the review flow to turn on Slack notifications for reviews

Why this matters

Reviewers can only approve what they can clearly see. Now you can check exactly what you are proposing before you send it, which means fewer review rounds spent on mistakes you could have caught yourself.

Try it out

Request a review on a gate or dynamic config rule change and open the preview in the review modal.

🩺 Warehouse Export Observability

You can now see when a warehouse export fails and why, without guessing or contacting support.

What you can do now

• Get a failure notification email when an export fails

• See the error message in the UI so you understand why an export failed

• Query export success and failure status programmatically with the new list-warehouse-export-status endpoint

• Ask the Statsig MCP to help you understand an export failure

Why this matters

A failed export used to be easy to miss and hard to diagnose. Now you hear about failures right away and can see the cause, in the UI, over the API, or through your AI tooling.

Try it out

Learn more in the Warehouse Exports docs and the export status API reference.

🔐 Entity-Level Create Permissions

Role permissions now extend to creating entities, not just editing and deleting them.

What you can do now

• Control who can create each entity type through role permissions, alongside the entity-level edit and delete permissions already available

Why this matters

You can now decide who is allowed to create new entities, so roles can match how your teams actually work without being over-permissioned.

Try it out

Learn more in the Statsig Access Management docs.

🤖 Statsig MCP v3

The Statsig MCP is now leaner for agents and covers far more of the Console API.

What you can do now

• Work with 18 default tools instead of 93, so agents spend less context on tool definitions and choose the right tool more easily. Additional operations are discovered on demand

• Use api_read, api_write, and api_destructive to discover and run Console API operations across Statsig without needing a dedicated MCP tool for each one

• Manage which users and projects can use MCP with self-serve access controls

Why this matters

Agents work better when they carry fewer tool definitions and can reach more of the platform. V3 gives you both, with governance you control.

Try it out

Learn more in the Statsig MCP Overview.

🎯 Choose Features for Contextual Bandits

You can now specify which context features a cloud contextual bandit trains on.

What you can do now

• Select the features in your context that the ML model should use for training

Why this matters

Not every attribute in your context should drive the model. Choosing the features yourself gives you control over what the bandit learns from.

🧹 Stale Dynamic Config Management

Dynamic configs can live for years without a clear cleanup point. Teams can now find likely cleanup candidates, understand why they were flagged, and decide what to do next.

What you can do now

• Temporary, Permanent, and Stale lifecycle states, with filtering in the Dynamic Config catalog

• Reason-specific guidance on the config page: configs with no recent checks can be archived, while intentionally long-lived configs can be marked Permanent

• A team-defined inactivity window (15, 30, 60, or 90 days; 30 by default)

• Periodic email, in-app, and Slack reminders based on notification preferences

• Lifecycle fields and filters in the Console API

Note: This is advisory only. A stale label does not change evaluation, disable a config, or archive anything automatically. This rollout does not include Feature Gate-only automation such as auto-archive, code-cleanup prompts or PRs, or bulk cleanup.

Why this matters

This closes a governance gap that several customers have raised and makes cleanup easier without introducing runtime risk.

Try it out

Check out the Feature Management page in your Statsig Console to evaluate config staleness.

🔐 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.

🔐 Entity-Level Edit and Delete Permissions

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.

🧪 Richer Experiment Configuration via MCP

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.