You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
/projects/{org}/{project}/rules/ (issue alert rules) was formally deprecated on 2026-05-14 with active brownouts — Sentry returns HTTP 410 GONE every 2 hours for 2 minutes. These are actively failing for users. This is urgent.
The replacement is /organizations/{org}/workflows/. sentry-mcp already uses this — see listIssueAlertRulesPage() there for the implementation pattern.
Different condition/action item schemas. Users pass legacy identifiers today — --condition '{"id":"sentry.rules.conditions..."}', --action '{"id":"sentry.mail.actions...","targetType":...}'. Workflows want {type, comparison, conditionResult} and {type, config, data}. The legacy→workflow translation lives in the backend (src/sentry/workflow_engine/migration_helpers/issue_alert_dual_write.py: translate_to_data_condition, build_notification_actions_from_rule_data_actions, plus special-cased conditions) and is impractical to replicate faithfully client-side.
detector_ids required. Issue alerts attach to a project's error detector ("Error Monitor"); create must resolve project → detector id (SDK listOrganizationDetectors).
Breaking contract. Migrating changes the documented --condition/--action JSON shapes, and edit's read-modify-write flips to reading/writing a workflow document (getOrganizationWorkflow).
Recommended next step: decide between (a) a CLI rewrite to the workflow schema, or (b) a backend rule-shaped compat write path reusing the existing dual-write translation.
Activity
fix(alerts): read issue alert rules from org-scoped /workflows/ (#1215)
betegon commentedon Jul 9, 2026
Migration progress
listIssueAlertsPaginated,getIssueAlertRule) →/organizations/{org}/workflows/— fix(alerts): read issue alert rules from org-scoped /workflows/ cli#1215 (merged)deleteIssueAlertRule) →DELETE /organizations/{org}/workflows/{id}/— fix(alerts): delete issue alert rules via org-scoped /workflows/ cli#1216 (draft)createIssueAlertRule,putIssueAlertRule) — deferred; research belowWhy create/edit are not a simple swap
Unlike reads/delete, the workflows write endpoint does not accept a legacy rule body. It expects a workflow-document model:
Blockers for the CLI:
--condition '{"id":"sentry.rules.conditions..."}',--action '{"id":"sentry.mail.actions...","targetType":...}'. Workflows want{type, comparison, conditionResult}and{type, config, data}. The legacy→workflow translation lives in the backend (src/sentry/workflow_engine/migration_helpers/issue_alert_dual_write.py:translate_to_data_condition,build_notification_actions_from_rule_data_actions, plus special-cased conditions) and is impractical to replicate faithfully client-side.detector_idsrequired. Issue alerts attach to a project's error detector ("Error Monitor"); create must resolve project → detector id (SDKlistOrganizationDetectors).--condition/--actionJSON shapes, and edit's read-modify-write flips to reading/writing a workflow document (getOrganizationWorkflow).Recommended next step: decide between (a) a CLI rewrite to the workflow schema, or (b) a backend rule-shaped compat write path reusing the existing dual-write translation.
fix(alerts): drop unused projectSlug from deleteIssueAlertRule
fix(alerts): delete issue alert rules via org-scoped /workflows/ (#1216)
feat(workflow_engine): type workflow request conditions/actions for S…
fix(alerts): read metric alert rules from org-scoped /detectors/ (#1275)
fix(alerts): create and edit issue alert rules via org-scoped /workfl…
fix(alerts): create and edit issue alert rules via org-scoped /workfl…
linear-code commentedon Oct 12, 2026
MCP-1075