Annie is Anyshift's CLI for turning graph context into reviewed actions. This article shows how `annie do` works with Sentry alerts.
Summary
During maintenance, silencing alerts is easy. Scoping the quiet window is where teams lose time.
In this demo, graph-connector (one of Anyshift's key services 😉) needs five quiet minutes. Annie's first move is to ask the Anyshift graph which production services depend on graph-connector during a deploy, and which Sentry projects cover them. Sentry knows the alert rules. Only the Anyshift graph knows the deploy-time path that links the deploying service to the other Sentry projects about to page. Annie returns that scope, the operator reviews it, then Sentry applies the quiet window through its own API.
For Sentry users, the difference is simple: Sentry keeps alerting. Anyshift supplies the production context that an alert rule cannot infer on its own.
The Problem
Deploy windows often start with guesswork. Someone picks the affected projects, finds the alert rules by hand, quiets them for the window, and hopes nobody forgets the cleanup.
Two things happen in real deploys: the quiet window is too broad, so unrelated production signals disappear. Or it is too narrow, and downstream teams still get paged for expected maintenance noise.
The pre-deploy Sentry workflow makes it smaller: build the affected-service context from production reality, review the proposed scope, then let Sentry apply the alert change.
The Context Anyshift Adds
The operator starts with one short request:
annie do "pre-deploy mute sentry for graph-connector for 5 minutes"Before Sentry receives a write, Annie attaches the context Anyshift gets from the graph:
1. Dependent services. The graph returns graph-connector plus every production service that depends on it during a deploy. This is the part Sentry can't compute on its own.
2. Sentry surface. Each service in scope maps to its Sentry projects through `SENTRY_DSN` references, environment metadata, and infrastructure context.
3. Sentry action. The request becomes a concrete action: which projects, which environment, and how long the quiet window lasts.
4. Evidence. The reviewer sees every Sentry project pulled in, with the dependency reason, before anything changes.
In Sentry terms, a DSN tells the SDK which project should receive events. An environment separates stages such as production and staging. An issue alert rule is the Sentry object that decides when to notify a team, using triggers, filters, and actions.
The handoff in one view: Anyshift resolves production scope, then Sentry reads the live rules and applies the window.
Annie saves the proposed scope and runbook before any write hits Sentry. Nothing changes in Sentry until the operator approves.
Operators phrase the same request in different ways:
annie do "pre-deploy mute sentry for graph-connector for 30 minutes"
annie do "snooze sentry alerts for ingest-worker during the migration"
annie do "suppress sentry issues for terraform-controller for 45m"Anyshift translates those requests into the same controlled action: scope the affected Sentry projects, stop for review, then apply a time-boxed quiet window in Sentry.
On approval, the runbook calls the Sentry API directly with the operator's local SENTRY_AUTH_TOKEN, lists the current issue-alert rules, and sets a quiet window with an until deadline. Anyshift never holds Sentry credentials.
Scope stays narrow: existing rules only, bounded window only. No rule creation, deletion, or threshold edits.
Sentry Owns The Rules
Before approval, nothing in Sentry changes. The graph-connector project has two alert rules, and the workflow reads their current state from Sentry.
The existing Sentry alert rules for graph-connector. Anyshift chooses the project scope; Sentry provides current rule state.
The detail view shows what the temporary quiet window is protecting: trigger history, production environment, throttling, and the notification action. Alerts stay configured in Sentry, and the quiet window applies only for the deploy window.
Sentry already gives teams release context, including deploy badges and graph markers in Release Details. Anyshift adds the dependency context before the alert change: which running services sit in the deploy path, and which Sentry projects can page during that window.
Sentry owns the rule config, notification action, and alert state. Anyshift brings the production graph into the decision.
Review Before Write
The runbook gives the operator one last check: selected project, quiet-window deadline, and API call. Review comes before any alert rule change.
Rule IDs are Sentry's identifiers for individual issue-alert rules. They appear in Sentry's API as rule_id, for calls such as /rules/{rule_id}/. The workflow fetches them late on purpose: Anyshift decides scope from production context first, then asks Sentry for the current alert rules after approval.
The saved plan joins the two facts that matter: Anyshift's production scope and Sentry's current rule state.
The division of labor is simple:
- Anyshift decides scope from code, infrastructure, deploy history, and runtime dependencies.
- The review step records the exact project, command, and deadline before approval.
- Sentry applies the change, checks auth, and expires it server-side.
Why It Matters
Sentry already gives teams the alerting primitives. The missing context is deployment scope: which service is changing, which projects can page during that change, and which alerts are expected noise for a few minutes.
When a team deploys graph-connector, Sentry sees the alert rules for each project. Anyshift sees the dependency path around the deploy: code, infrastructure, deploy history, and runtime relationships.
For Sentry users, that means fewer noisy deploy windows, less risk of quieting unrelated projects, no stale spreadsheet of "services to silence," and one saved artifact explaining why each project was touched.
Temporary alert changes should be boring: precise, reviewable, and easy to trust.
If your team uses Sentry and wants maintenance windows that follow production reality instead of a manual checklist, contact us.
