Find which feature flag caused your Sentry error spike

When Sentry fires an issue alert for an error that is spiking or has newly regressed, I want an agent to work out whether a recent feature flag change caused it. Trigger this workflow from a Sentry outgoing webhook on issue alerts, and read the issue id, project and organization out of the webhook payload.

Start by building a picture of the error. Use the Sentry "List an Issue's Events" operation to pull recent events for the issue so you have the stack trace, the file paths and function names in it, the affected release, and any tags identifying the service or environment. Use "List Organization Issues" to see the issue in context and establish when the error volume actually started climbing, which is the spike time everything else is measured against. Be precise about that timestamp, because the whole correlation depends on it.

Then look at what changed in LaunchDarkly. Query "List audit log entries" for the 24 hours before the spike started, filtering by that date range, to get every flag change in the window along with who made it and when. Treat each changed flag as a candidate.

For each candidate flag, gather the detail you need to judge it. Use "Get feature flag" to read the flag's name, description and tags, and "Get flag status across environments" to see whether it is currently on in the environment where the error is happening. If an audit entry is ambiguous about what actually changed, use "Get audit log entry" to see the before and after state.

Now rank the candidates by how likely each one is to be the cause. Weigh two things. First, timing overlap: how tightly the flag change lines up with the moment errors began climbing, where a change minutes before the spike matters far more than one twenty hours earlier. Second, relevance: whether the flag key, its description or any of its tags match something in the stack trace, the affected release, or the name of the service that is failing. A flag that scores on both is a strong suspect. A flag that scores on neither should be left off the list rather than padded in. If nothing correlates, say so plainly instead of naming a weak suspect.

Post the result to Slack with "Send a Message" to the on-call channel. Name the top suspects in rank order, and for each one give the flag key, who changed it, when they changed it, what the change was, and whether it is currently on in the affected environment. Explain in one line why each flag is suspected, referencing the timing or the specific stack trace match. Include a link to the Sentry issue and state the recommended kill switch, meaning the exact flag a human should turn off first if they decide to roll back.

If the error volume is above our paging threshold, also open a PagerDuty incident with "Create Incident" and put the same flag analysis in the incident body, so whoever gets paged starts with the suspect list rather than a bare error count. Below that threshold, the Slack message alone is enough.

Never toggle, disable or otherwise modify a feature flag automatically. This workflow only reads from LaunchDarkly and recommends an action. A human must always confirm a production rollback.