Production Sentry Ownership - Eliminate the Dedicated Role; the Skill Is the Continuity

Proposer: Chuck Lin

Date: June 24, 2026

Revised: June 30, 2026 — incorporating the June 29, 2026 “Pass first responder baton” meeting

Status: Seeking Advice

Generated from the June 23, 2026 Momentum Synch-up (where the “Sentry responder” discussion surfaced more open questions than answers) and a follow-up problem-definition session. The meeting conflated several things; Discovery below records how the scope was narrowed, and Debate records the competing arguments and the strategies considered.

🔁 Revision summary (June 30). The June 29 “Pass first responder baton” handoff meeting changed the premise of this proposal. The Claude Sentry skill is materially more capable than the June 24 draft credited it: it already scans the prod board, classifies each issue (including infra/third-party), performs and posts a root-cause analysis, opens the GitHub bug, proposes a fix via PR, and resolves the Sentry issue itself once the fix has shipped — without a human marking the board. That dissolves the two “concrete failures” that motivated a dedicated owner (issues never closed in Sentry; no cross-day memory). (Implementation note, June 30: the auto-resolve step was wired into the skill in momentum PR #18314 — it did not exist when the June 29 meeting credited it. It is next-run reconciliation, not instantaneous: on the scheduled pass after the fix PR merges and the issue has gone quiet, the skill marks it resolved in Sentry. It never closes an issue still throwing after its fix (that’s treated as recurrence), and never acts on a draft/unmerged fix.) The direction therefore pivots from Strategy D (“manufacture continuity without a new role”) to eliminating the dedicated Sentry responder/steward role altogether (new Strategy E). The continuity now lives in the skill; the existing daily Bug Swatter operates and verifies it. Below, the original June 24 analysis is preserved as the historical record and annotated with marked 🔁 Revised June 29 notes and rationale wherever the meeting overturned an assumption.

Proposal

Problem Statement

We need a durable way to own production Sentry — triaging what fires, classifying each notification, recognizing when an issue recurs or escalates over time, and tracking every real issue back to closed in Sentry — without adding a new standing role, because the developer pool is already fully allocated.

The work is not simply “fix bugs.” Each prod Sentry notification is one of:

• a true new bug → file/assign a GitHub issue and fix it;
• an operational blip (e.g. a system briefly down, maintenance) → no GitHub issue, just acknowledge/close; or
• a re-trigger of a known, low-priority, silenced bug → recognize it as the old one and leave it.

Classifying these correctly and quickly depends on historical memory, which a person who only holds the role for a single day does not have.

🔁 Revised June 29. Classification and historical memory are now carried by the Claude Sentry skill, not by a person. The skill opens an issue even for infrastructure/third-party errors (labeling them as infrastructure rather than a software bug — “It’ll just say this is an infrastructure”), and it remembers and resolves across days. Rationale: the crux of the original argument — “fast, correct classification requires a person who remembers the history” — no longer holds once the tool holds the history. The human’s job shifts from remembering and classifying to verifying the skill classified and closed correctly.

Goals

1. Guarantee every real prod Sentry issue is tracked to closed in Sentry, even when it is fixed days later by a different person.
2. Preserve the long-term perspective — recurring throws, slow escalations, and known-silenced re-triggers — that a daily-rotating owner cannot see.
3. Add zero new standing roles.
4. Keep same-day responsiveness and off-hours coverage using mechanisms that already exist.

🔁 Revised June 29. Goal 3 strengthens from “add zero new roles” to “do not maintain a dedicated Sentry role at all.” Goals 1 and 2 are now met by the skill (auto-closure; cross-day scan) rather than by a human convention. Rationale: the meeting concluded the skill already satisfies 1 and 2, so the only remaining question is who operates and verifies it — answered below by folding the task into the existing Bug Swatter rotation.

Proposed Direction (Revised June 29 — pending consent)

[Superseded] The original June 24 direction — “manufacture continuity from a first-touch-owns-to-closure convention, the skill’s weekly report, and a standing review in the existing devops meeting” — is preserved in the Debate → Strategy D section below. It is superseded by the direction here, which the June 29 meeting moved toward.

The recommendation is to eliminate the dedicated Sentry responder/steward role and let the skill be the system of record:

1. No dedicated Sentry role. There is no standing “Sentry responder/steward” as a distinct workload. This directly answers Chuck’s action item from the meeting — to propose “how we’re going to change this role or whether or not to even have it anymore.” This proposal answers: eliminate it.

2. The Bug Swatter operates the skill. Whoever holds the daily Bug Swatter rotation runs the Claude Sentry skill, reviews its root-cause output for accuracy, and babysits it to a clean finish — “Whoever is the bug swatter should just run the skill… and you just have to sit there and babysit the thing.” Their accountability is to confirm each issue is closed in both GitHub and Sentry (“run the skill, then be really responsible on making sure that it fully closes this loop of closing it”).

3. Definition of done = empty board at sprint end. The standard is zero bugs open at the end of every sprint, which requires the Sentry board to be clear (Sentry issues become bug tickets). The volume is low enough that this is “not that big a deal” a couple of times a sprint.

4. Continuity lives in the skill, not a person. The June 24 “first-touch owns to closure” human convention is downgraded: the skill resolves the Sentry issue itself on the next run after the fix ships and the issue quiets (“Oh no, it closes it for you… You just go make sure you resolved it”) — see the June 30 implementation note above — so the human’s job is verification, not manual multi-day tracking.

5. Weekly review folds into the existing DevOps meeting. No separate Sentry/on-call meeting. The Sentry/on-call items run at the end of the existing weekly DevOps meeting (which already runs under 15 minutes); non-relevant attendees (e.g. Ruben) are dismissed before that portion. Chuck remains the standing DevOps presence for SOC2 purposes — as Bomee put it, “that person is Chuck… it kind of still has to take residence in your brain.” This resolves the June 24 open question of who anchors the review.

6. Accountability is social, owned by the Tech Lead (Chuck). If someone leaves Sentry issues unclosed during their rotation, Chuck calls it out (“the first time… you don’t do it, Chuck, you’re going to yell at them”). No new process — just follow-through.

7. On-call / triage paging is unchanged. The primary/secondary “is the site up?” paging rotation is a separate concern and continues as-is. The on-call system still designates a weekly Sentry-notification recipient via the Cloudflare-backed config (Chuck set himself and Naina this week) — but that is notification routing, not a separate workload role.

Success Criteria (Revised June 29)

• The prod Sentry board is empty at the end of every sprint.
• During their rotation, the Bug Swatter runs the skill and confirms each issue is closed in both GitHub and Sentry.
• No dedicated Sentry role exists.
• Pattern/health review happens at least weekly, inside the existing DevOps meeting — no new meeting.
• Off-hours “is the site up?” coverage continues via the triage paging rotation.

Validation plan (from the meeting)

• Trial the folded meeting next cycle. François: “Let’s do it next cycle because it’s the first time we see the [new structure].”
• Reconvene in ~2 weeks. François and Chuck reconvene roughly two weeks after June 29 to confirm the board stays clean under this process without special intervention (“we give that a shot and we meet again in two weeks”).
• Right-size the handoff meeting. Ideal attendance for the baton handoff is four people: Chuck, François, the outgoing responder, and the incoming responder.

---

Advice Process

Steps:

1. Discovery: Ask questions to understand the proposal.
2. Debate: Explore risks, concerns, alternatives, and identify critical questions related to the actions proposed.
3. Decision: Finalize a “safe to try” approach with consent from all stakeholders.

Please start by adding your comments in the PR.

Discovery

Clarifying questions narrowed a broad, tangled discussion down to a single problem:

• Scope is production Sentry only. Dev and staging Sentry are already owned by the Release Manager during promote/release. SOC2 ownership sits with the infrastructure team (not a developer on this team); we satisfy SOC2 simply by everyone handling prod issues properly, not by designating a compliance owner here. Escalation/on-call is a separate concern (see triage below).

  🔁 Revised June 29. SOC2 still needs a standing DevOps presence to show up to the meeting; the meeting identified that person as Chuck (“somebody needs to show up for SOC 2 purposes, to continue to have… a DevOps meeting… that person is Chuck”). Rationale: this does not reintroduce a Sentry role — it confirms the existing DevOps cadence (chaired by Chuck) is where the Sentry review lands.

• The work is classification, not just fixing. As above, a notification may be a new bug, an operational blip with no GitHub issue, or a re-trigger of a known-silenced bug. Fast, correct classification requires knowing the history — this is the crux of the continuity argument.

  🔁 Revised June 29. The skill now does the classification, including the infra-vs-software-bug distinction (it can be adjusted in the skill if a category needs different handling). Rationale: the “crux of the continuity argument” is the assumption this revision overturns — classification is now a tool capability, so it no longer requires a long-tenure human.

• Sentry is spiky and needs in-the-moment responsiveness — but the “is the site up?” half of responsiveness is already solved. The triage paging rotation handles it: when Sentry alarms the on-call system, the primary has 15 minutes to acknowledge the site is functional; if not, the backup is paged; if still unacknowledged, a general notification reaches everyone. This rotation spans the entire company, including non-programmers (customer support, HR, etc.), and runs around the clock. Triage is not the same as the Sentry person — triage confirms the site is alive; it does not troubleshoot.

• People are the binding constraint. There are 5 developers including Chuck eligible for these responsibilities (Bomee is not in the operational roles). Of those, two are consumed for a full month each by Tech Lead and Release Manager, and every developer also carries a daily Bug Swatter rotation plus their own software-development project work. There is no room for an additional standing role.

  🔁 Revised June 29. This constraint is now dispositive, not just limiting: because the skill does the loop, the rational response to “no room for another role” is not to squeeze one in cleverly but to not have a Sentry role at all and attach the (small) verification task to the Bug Swatter who is already on rotation.

• Timezone concentrates the load on one person. Most prod issues fire during US-East-Coast hours, when only Chuck is a fully-online developer. The other four developers are in Portugal, Romania, Turkey, and Ukraine. Jason (US) is accustomed to looking at Sentry but is not a developer and may not be able to troubleshoot — so he cannot be the Sentry person.

  🔁 Revised June 29. With the skill doing root-cause analysis and proposing fixes, the troubleshooting depth required of the operator drops — the operator verifies and babysits rather than diagnoses from scratch — which further weakens the case for a single dedicated (and timezone-constrained) owner.

• Two concrete failures the status quo allows: (a) an issue fixed several days after it first appeared is never marked resolved in Sentry, because no one tracked it across days; and (b) a daily-rotating Bug Swatter cannot recognize that a given throw has recurred or is escalating over a span of days.

  🔁 Revised June 29 — both failures now addressed by the skill. (a) The skill resolves the Sentry issue on the scheduled run after its fix merges and the issue stops firing (see the June 30 implementation note above), so a fix that ships days later still gets the board marked — no one has to remember to close it. (b) The skill scans the whole board on each run (Bomee had been clearing 90-day-old issues), so recurrence/escalation is visible from the tool rather than from a person’s memory. Rationale: these two failures were the entire empirical case for a dedicated owner; with both closed by the tool, the role’s justification largely disappears.

Debate

The core contention.

• Bomee’s position: the Sentry-response person can simply be the daily Bug Swatter — there is no need for a separate role, especially because (i) the team genuinely has no headcount for another role on top of Tech Lead, Release Manager, the daily Bug Swatter, and each developer’s project work, and (ii) in her view there are not that many prod Sentry issues to begin with.

• Chuck’s position: because the Bug Swatter is elected daily, that person has no longer-term perspective on underlying issues. Recurring throws, slow escalations, and known-silenced re-triggers are only visible to someone watching across days. And without a person tracking an issue over multiple days, an issue fixed later never gets closed in Sentry. (Note: Bomee’s “near-zero volume” read is contested — much of the volume is notifications to interpret, not bugs to fix: system-down alerts with no GitHub link, and silenced low-priority bugs that re-trigger because their ticket was never assigned or worked.)

• The constraint both sides accept: no new standing role is affordable.

🔁 Revised June 29 — the contention is resolved by capability, not compromise. Chuck’s objection rested on “longer-term perspective only a person can hold” and “issues fixed later never get closed.” The June 29 meeting established that the skill holds the longer-term perspective (full-board scan) and closes Sentry automatically. With Chuck’s two load-bearing objections answered by the tool, the team converged on Bomee’s shape — the Bug Swatter runs the skill — but pushed it one step further than her original framing: not “the Bug Swatter is the Sentry person,” but “there is no separate Sentry person; the Bug Swatter operates a skill that is.” See new Strategy E.

Strategies considered.

Strategy A — Bundle into the daily Bug Swatter (Bomee’s position). No separate role; Sentry response is part of the Bug Swatter’s day. Strengthened by the first-touch-owns-to-closure convention so individual issues are tracked across days; pattern recognition leans on the weekly devops meeting and the Sentry skill.

• Pros: simplest; consumes zero extra people.
• Cons: continuity lives only in the convention and tooling, never in a person’s memory; the “is this the known-silenced one?” judgment stays hard for a fresh daily owner. Closest to the status quo and does not, on its own, answer Chuck’s objection.

Strategy B — Dedicated Sentry Steward on a longer rotation (Chuck’s pure position). A separate named role held ~2 weeks or a sprint, owning the prod board: triage, classify, pattern-recognize, drive closure; the Bug Swatter only fixes what is routed to them.

• Pros: strongest continuity and pattern recognition; one unambiguous owner; the weekly review has a real person behind it.
• Cons: rejected on headcount — it consumes another developer from a pool already down to ~3 after Tech Lead and Release Manager. Timezone also undercuts it: an EU-based steward is offline during US-hours spikes, so same-day response still falls to whoever is online; the steward’s value would be continuity, not real-time response.

Strategy C — Hybrid: daily first-touch + a lightweight longer-tenure steward. Bug Swatter does day-of first-touch and self-assign-to-closure; a longer-tenure steward does no daily work, only a weekly cross-day review (re-triggers, escalations, unclosed issues) brought to the devops meeting, with the Sentry skill automating the scan.

• Pros: concedes Bomee’s day-of point and secures Chuck’s cross-day point.
• Cons: if the steward is treated as a role, it still costs headcount the team does not have — which is why it collapses into Strategy D.

Strategy D — No new role: convention + automation + existing-meeting review (June 24 recommended synthesis). Manufacture continuity from the three headcount-free levers: (1) the first-touch-owns-to-closure convention carries per-issue continuity at zero people cost; (2) the Sentry skill holds the cross-day memory and emits a weekly report; (3) that report is reviewed as a standing item in the already-existing weekly devops meeting. Day-of response stays with the Bug Swatter; off-hours stays with triage paging.

• Pros: answers Chuck’s continuity objection without the role Bomee says we cannot afford; most defensible in consent because it gives both sides their core need instead of picking a winner.
• Cons: two new concepts to socialize; the convention must actually be followed for closure to hold; needs one accountable owner for the weekly report to avoid diffusion of responsibility.

🔁 Revised June 29 — Strategy D is superseded by Strategy E. D still assumed a human convention had to “manufacture” continuity and that a person had to own closure. The meeting showed the skill closes Sentry itself, so D’s central human mechanism (first-touch-owns-to-closure) is unnecessary as a tracking device and survives only as a verification expectation on the Bug Swatter.

Strategy E — Eliminate the role; the skill is the continuity, the Bug Swatter operates it (recommended, June 29). No dedicated Sentry responder/steward exists. The Claude Sentry skill performs the end-to-end loop (scan → classify, incl. infra → root-cause analysis → open GitHub bug → propose fix/PR → close Sentry on resolution). The daily Bug Swatter runs the skill, verifies its output, and confirms closure in both GitHub and Sentry. Cross-day/pattern review is a fixed item at the end of the existing weekly DevOps meeting (Chuck the standing presence for SOC2). Off-hours stays with triage paging.

• Pros: zero dedicated headcount; continuity is in the tool, not fragile human memory; answers Chuck’s two objections by capability rather than compromise; no new meeting; smallest set of new concepts to socialize.
• Cons: depends on the skill staying reliable (hence the 2-week reconvene to confirm the board stays clean); the Bug Swatter must actually run and babysit it each rotation; the infra-vs-software-bug categorization may need ongoing tuning in the skill; Chuck remains a single point of presence for the DevOps/SOC2 cadence.

Who owns the weekly review — resolved.

🔁 Revised June 29. The June 24 draft left this contingent between Tech Lead and a rotating facilitation duty (Release Manager ruled out). The meeting resolved it to the Tech Lead (Chuck), who must already attend the DevOps meeting for SOC2 and in whose head the cadence “takes residence.” The original analysis is retained below for the record.

(Original June 24 analysis — retained as historical record.) Strategy D needs a single owner to ensure the weekly Sentry report is generated and walked through — this cannot be “everyone” or it becomes no one. But who that is falls out of how we decide to treat the Sentry role; it is not picked separately. Candidates, each attaching the task to an existing role rather than creating a new one:

• Tech Lead — an oversight/health role; “prod Sentry health” fits the remit.
• Release Manager — ruled out. Both the current and previous Release Managers have objected to also taking on prod Sentry: the RM already has to stay on top of every dev and staging Sentry issue, and that job is already very full. Bundling prod Sentry onto the RM is not viable.
• Rotating facilitation — whoever chairs the devops meeting that week generates it (reintroduces minor rotation overhead).

Because the RM is out and a dedicated steward is unaffordable (Strategy B), the realistic anchors are the Tech Lead or a rotating devops-meeting facilitation duty — and which one applies depends on the role-treatment decision the consent meeting lands on.

Other points raised. Calc Service mirrored this rotation “for parity,” but parity is not required — each team can run what works for it. The existing Sentry skill can also be run at promote time so throws on main are caught before they reach staging/prod.

🔁 Revised June 29 — Calc Service. Calc Service runs its own Sentry responder (identified in the meeting as Mark); Momentum does not handle Calc Service issues. A recurring N+1 issue on Calc Service was discussed — Chuck closed one that morning, fixes are already in progress, and Ana resolved a similar one last week by tagging Calc’s Sentry responder. Rationale: reinforces that parity is not required and that Calc’s ownership is out of scope for this proposal.

Decision

Please situate yourself in a stakeholder category.

🔁 Operational decisions already agreed in the June 29 meeting (recorded here; the consent decision below ratifies the role question):

• Fold Sentry/on-call into the existing weekly DevOps meeting — no separate meeting. Non-relevant attendees (e.g. Ruben) are dismissed before the Sentry portion at the end. Trial this structure next cycle.
• Right-size the handoff to four people: Chuck, François, the outgoing responder, the incoming responder.
• Reconvene (François + Chuck) in ~2 weeks to confirm the board stays clean under the skill-run process.
• Operational follow-ups (Chuck): update Bomee’s on-call hours to 6:30am–11:00pm Eastern; remove the stale schedule/time columns from the on-call spreadsheet (keep only channel assignments); investigate placing the on-call system’s web interface behind Cloudflare Access on port 80 as a separate app reusing the existing policy, so phone acknowledgments are not blocked.

The role question for consent: Eliminate the dedicated Sentry responder/steward role (Strategy E). The skill is the continuity; the daily Bug Swatter operates and verifies it; the Tech Lead (Chuck) anchors the weekly review inside the existing DevOps meeting.

Consent

• Bomee Jung
• Maksym Khrystunov
• Jason
• İlayda Çavuşoğlu
• Ana Lisboa
• Chuck Lin

Advice

• Naina Shah (Calc Service)
• Robin Neri
• François Huet