Use GrowthBook with Sazabi: check flag changes while you debug

Last verified on Nov 8, 2026.

Most production incidents start with a change, and a feature flag is the change that never shows up in a deploy log. A rollout moved from 10% to 50%, a targeting rule picked up a new segment, or an environment toggle flipped. When errors start at 14

Sazabi is AI-native observability and security. Connect GrowthBook and the Sazabi agent can answer that question from the same thread where it is reading your application logs.

What the Sazabi agent can do with GrowthBook

The connector is an MCP connector pointed at GrowthBook's hosted server. You authorize once with OAuth. The Sazabi docs page lists what the agent can do:

• Read feature flags, variations, targeting rules and rollouts.
• Review experiment status, results and metric variations.
• Query projects, environments and metrics.
• Use GrowthBook's agent skills and workflows.

Behind that list, GrowthBook's server is a thin layer with four tools. growthbook_list_skills and growthbook_read_skill load GrowthBook's bundled workflows. growthbook_api_read makes authenticated GET calls to the REST API, and growthbook_api_write handles POST, PUT, PATCH and DELETE. GrowthBook's own docs note that these API tools pass requests through without validating payloads, which is a reason to keep writes off unless you need them.

Two endpoints from GrowthBook's REST docs matter most while debugging. GET /v2/features/{id} returns a flag with its rules in every environment, and GET /v1/experiments/{id}/results returns the latest analysis for an experiment.

Questions it answers

• What are the current rules for the new-checkout-flow flag in production?
• Which environments have this flag turned on?
• Is the experiment running on the affected page still live, and what does it say about the variation?
• Which projects and environments does this GrowthBook organization have?
• Which metrics does the experiment track, so I know what moved?

A worked example: errors that begin with a rollout

Say your checkout service starts returning 500s from one code path. In a Sazabi thread you ask:

Checkout 500s started around 14:05 UTC. Using GrowthBook, show the rules
for the new-checkout-flow flag in production, and tell me whether the
checkout-copy experiment is still running. Then compare with the error
logs from that time.

The agent calls growthbook_api_read with GET /v2/features/new-checkout-flow. The response shows a rule that forces true for a saved group, with coverage at 50%. It then reads GET /v1/experiments and checks the status of checkout-copy. Finally it searches your logs for the same window and reports whether the failing requests carry the new code path's log message.

You end up with a short answer: the flag's rule, the experiment's status and the log lines that line up with them. The agent does not have to change anything to give it. If you decide to turn the flag off, the REST API has POST /v2/features/{id}/toggle, which needs a write-enabled connection, and GrowthBook's Human-in-the-Loop preset would hold that change until someone confirms it.

Choosing how much access to give

GrowthBook's consent page offers Read only, Human-in-the-Loop (default) and Full access, or custom permissions. Sazabi adds its own read-only toggle on top. GrowthBook also offers an /mcp/api endpoint with just the two API tools, if you do not want its skills in the mix. For investigations, read-only is enough: reading flag rules answers most incident questions.

How it fits with other integrations

Flag state is one side of the picture. The other side is your telemetry, which you can send through OpenTelemetry or a webhook. If your flags and services run on a cloud, AWS logs add the infrastructure view. Related tools sit in cloud platforms, and the whole catalog is at integrations. See pricing for Sazabi plans.