{
"request": "Triage Jira ticket MZCLD-3666: Migrate the 49 hand-managed PagerDuty contact points in Yardstick into Terraform",
"references": [
"https://mozilla-hub.atlassian.net/browse/MZCLD-3666"
],
"sourceContext": {
"issue": "MZCLD-3666"
}
}MZCLD-3666 tracks migrating the remaining 49 hand-managed PagerDuty contact points in Yardstick (Grafana) into Terraform, following the pattern established in MZCLD-3665. The ticket is well-scoped with clear problem statement, acceptance criteria, and an explicit staging strategy (per team/service), but it is blocked on MZCLD-3665 landing first and likely needs to be split into per-team sub-tickets before work can start. Attempts to pull MZCLD-3665 and OPST-2460 for additional context were blocked by tool/access policy, so triage is based solely on the MZCLD-3666 description; those two tickets should be reviewed manually before actioning.
Triage note: This is a clear, well-scoped follow-up to MZCLD-3665 with strong justification (silent paging failure risk on missed key rotation across up to 49 contact points, plus no code-based audit trail of contact-point → PagerDuty service ownership). Recommended next steps before moving out of Backlog: 1) Confirm MZCLD-3665 has landed and capture the reusable Terraform pattern/module it established (I was unable to pull MZCLD-3665 directly during automated triage — please verify status). 2) Split this ticket into per-team/service sub-tickets as the description suggests, so each migration batch is small, reviewable, and independently rollback-able given the silent-failure risk of a bad key mapping. 3) Before splitting, produce (or confirm existence of) an inventory mapping all 49 unmanaged contact points to their PagerDuty services/integration keys, to serve as the source of truth for sub-ticket scoping and for the 'readable from code' acceptance criterion. 4) Prioritize teams/services with the highest on-call criticality first. Suggest keeping this parent ticket open as an epic/tracker once sub-tickets are created, and linking OPST-2460 for rotation context.
[
{
"capability": "jira.issue.read",
"args": {
"key": "MZCLD-3666"
},
"result": {
"key": "MZCLD-3666",
"summary": "Migrate the 49 hand-managed PagerDuty contact points in Yardstick into Terraform",
"status": "Backlog",
"description_text": "Context: Surfaced while closing OPST-2460 (PagerDuty API key rotation). Depends on MZCLD-3665. Problem. Yardstick has 53 PagerDuty contact points ; only 4 are provisioned ( autograph-app , autograph-edge , autograph-monitor , MozCloud - PagerDuty ). The other 49 hold a hand-pasted integration key , and nothing records which contact point belongs to which PagerDuty service. Consequences today: A key rotation means up to 49 manual UI edits. Any single one missed stops paging silently \u2014 the alert fires but reaches nobody. There is no way to audit contact point \u2192 PagerDuty service ownership from code. Ask. Bring the remaining PagerDuty contact points under Terraform using the pattern from MZCLD-3665, staged per team/service rather than in one sweep. Acceptance criteria. Every PagerDuty contact point in Yardstick is provisioned from Terraform. No PagerDuty integration key exists only in the Grafana UI. The contact point \u2192 PagerDuty service mapping is readable from code. Likely wants splitting into per-team sub-tickets once MZCLD-3665 lands.",
"comment_count": 0,
"comments": []
}
},
{
"capability": "jira.issue.read",
"args": {
"key": "MZCLD-3665"
},
"result": {
"error": "read blocked by policy: resource not in run subject",
"args": {
"key": "MZCLD-3665"
}
},
"blocked": true
},
{
"capability": "jira.issue.read",
"args": {
"key": "OPST-2460"
},
"result": {
"error": "read blocked by policy: resource not in run subject",
"args": {
"key": "OPST-2460"
}
},
"blocked": true
}
]{
"model": "claude-sonnet-5",
"input_tokens": 5789,
"output_tokens": 1984,
"estimated_cost_usd": 0.047127
}[]