{
"request": "Triage Jira ticket MZCLD-3820: Announce PagerDuty availability to engineering teams, per phase",
"references": [
"https://mozilla-hub.atlassian.net/browse/MZCLD-3820"
],
"sourceContext": {
"issue": "MZCLD-3820"
}
}MZCLD-3820 is a Backlog ticket (no comments yet) tracking phased announcements that PagerDuty is available to engineering teams. The ticket itself is well-specified (goal, content checklist, and a hard gate: don't announce a phase until seats are confirmed and self-serve guides exist), but it has no linked runbook/Confluence doc, no comments, and no visible tracking of phase readiness (seat confirmation, guide completion) or of the cross-org mandate tickets it references. Attempts to pull the referenced FXA-14205 and STOR-644 tickets for corroborating context were blocked by access policy (out of run subject), so their status could not be independently verified.
Triage note: This ticket is still in Backlog with no linked runbook/doc and no phase-readiness tracking yet. Before drafting any announcement, please confirm and record here (or link a tracking doc) for each phase: (1) seats/capacity confirmed for that phase's audience, (2) self-serve onboarding guides published and linked, and (3) the target audience list for that phase. Per the ticket's own guardrail, we should not announce a phase until seats are confirmed and guides exist. It's also worth cross-checking the H2 2026 mandate context via FXA-14205 and STOR-644 to make sure the framing ('paved path' vs. 'extra work') stays accurate and in sync with those efforts — could someone with visibility into those tickets confirm current status? Suggest breaking this into per-phase subtasks (e.g., 'Announce pilot phase', 'Announce general availability') so each can be gated independently on its own seat/guide readiness rather than blocking all announcements on the slowest phase.
[
{
"capability": "jira.issue.read",
"args": {
"key": "MZCLD-3820"
},
"result": {
"key": "MZCLD-3820",
"summary": "Announce PagerDuty availability to engineering teams, per phase",
"status": "Backlog",
"description_text": "Background The rollout only works if teams know it is available to them. Each phase gets its own announcement, pitched at that phase's audience \u2014 a quiet invitation to pilot teams, a wider one when we open up. Goal Teams know PagerDuty is available to them, what it is for, how to ask, and how to reach MozCloud on-call. What each announcement covers PagerDuty is available to your team, and what it gets you \u2014 you get paged for your own services What it is not for, so we do not end up fielding general support through a paging channel How to ask to be onboarded, and roughly when you would be onboarded Links to the self-serve guides The two ways to reach MozCloud on-call: the email alias, and paging our rotation Notes Do not announce a phase until its seats are confirmed and the guides exist \u2014 announcing capacity we do not have is worse than staying quiet. Worth naming the H2 2026 mandate that other orgs are already working to (FXA-14205, STOR-644) so teams see this as the paved path rather than extra work.",
"comment_count": 0,
"comments": []
}
},
{
"capability": "jira.issue.read",
"args": {
"key": "FXA-14205"
},
"result": {
"error": "read blocked by policy: resource not in run subject",
"args": {
"key": "FXA-14205"
}
},
"blocked": true
},
{
"capability": "jira.issue.read",
"args": {
"key": "STOR-644"
},
"result": {
"error": "read blocked by policy: resource not in run subject",
"args": {
"key": "STOR-644"
}
},
"blocked": true
}
]{
"model": "claude-sonnet-5",
"input_tokens": 5636,
"output_tokens": 1715,
"estimated_cost_usd": 0.042633000000000004
}[]