8 Claude Cowork Automations for DevOps and SRE Teams

Pull the on-call handoff data for the shift ending now. Include:
- PagerDuty: all alerts in the last 24 hours, current open incidents, any acknowledged but unresolved alerts
- Datadog: current service health for [SERVICE LIST], any monitors in alert or warn state
- Recent post-mortems: any action items due or overdue this week

Structure the output as:
1. Open Incidents (status, impact, current owner)
2. Alerts to Watch (elevated risk, not yet triggered)
3. Pending Action Items (from last 3 post-mortems)
4. Service Health Summary (green/amber/red per service)
5. Handoff Notes (anything the incoming engineer needs to know that data doesn't capture)

Keep it readable in under 5 minutes. Flag anything that requires immediate attention.

An alert has fired: [ALERT NAME] on [SERVICE] at [TIME].
Alert details: [PASTE ALERT BODY]

Search the runbook library for [SERVICE] and retrieve:
1. The relevant diagnostic checklist for this alert type
2. Known root causes for this alert pattern
3. The escalation path if initial diagnosis doesn't resolve it
4. Links to the last 2 incidents with this same alert

Post the diagnostic steps formatted for a Slack message — brief, actionable, with commands ready to copy.

Read all post-mortems published in Confluence in the last 90 days. Extract every action item with its assigned owner and due date.

For each action item:
1. Find the corresponding Jira ticket (search by title or post-mortem reference)
2. Get the current status: Done, In Progress, To Do, or No Ticket Created
3. Calculate if it's on time, due soon, or overdue

Produce a report with:
- Summary: X of Y action items completed, Z overdue
- Overdue items (sorted by how overdue they are)
- Items due this week
- Items with no Jira ticket created (the accountability gap)

Format for a Slack post. Flag any post-mortem that has zero completed action items after 30 days.

Assess the deployment risk for this PR: [LINK OR PASTE DIFF]
Service: [SERVICE NAME]
Deployment window: [DATE/TIME]

Read the service runbook [attached] and the last 5 incident post-mortems [attached].

Produce a risk assessment with:
1. Change summary (what changes, 3 sentences)
2. Risk factors identified (each with: what it is, why it's risky, likelihood, impact)
3. Similar past incidents (from the post-mortems — any pattern matches?)
4. Pre-deployment checklist (service-specific, not generic)
5. Rollback procedure for this specific change
6. Recommended monitoring for 4 hours post-deployment

Risk level: Low / Medium / High / Block (with justification).
Be specific. "Database schema changes with no migration rollback script" is useful. "This looks risky" is not.

Convert this Terraform plan output into a change management document:
[PASTE TERRAFORM PLAN OUTPUT]

Include:
1. Plain-English summary of what changes (avoid Terraform jargon)
2. Resource inventory: new resources, modified resources, destroyed resources
3. Estimated impact: what systems/services are affected, any downtime expected
4. Rollback plan: terraform state commands and manual steps if needed
5. Dependencies: what other infrastructure does this change depend on or affect
6. Validation steps: how to verify the apply succeeded

Format for Confluence. Add a one-paragraph executive summary at the top for stakeholders who won't read the technical detail.

Produce an on-call onboarding document for [SERVICE NAME] for an engineer who knows our stack but is unfamiliar with this service.

Use these sources:
- Service repository [attached/linked]
- Current runbook [attached]
- Last 10 incident post-mortems [attached]
- Architecture diagram [attached if available]

Structure:
1. What This Service Does (2-3 paragraphs, business context + technical role)
2. Architecture Overview (key components, dependencies, data flow)
3. How to Access and Monitor (dashboard links, log locations, key metrics)
4. The 5 Most Common Incidents (each: symptoms, likely cause, first response steps)
5. Escalation Path (who to call and when)
6. Things That Look Scary But Aren't (common false alarms)
7. Things That Look Fine But Aren't (subtle early warning signs)

Aim for a document a new on-call engineer can read in 30 minutes and feel prepared.

Produce the monthly SLO review for [MONTH YEAR].

Data sources:
- Datadog SLO performance: [paste or attach monthly export]
- Incident log for [MONTH]: [attach post-mortem list]
- Previous 2 months SLO data: [attach for trend comparison]

Report sections:
1. Executive Summary (5 bullets — for VP Engineering, 2-minute read)
2. SLO Performance by Service (table: service, SLO target, actual, delta, error budget remaining)
3. Error Budget Analysis (which services are burning budget faster than planned)
4. Incident Impact (total downtime, P1/P2 breakdown, MTTR by severity)
5. Month-over-Month Trends (improving, degrading, stable — per service)
6. Top 3 Reliability Risks for Next Month (specific, not generic)
7. Recommended Actions (prioritised by impact, with suggested owners)

Flag any service approaching error budget exhaustion before the next review period.

Analyse our runbook coverage and identify gaps.

Sources:
- Confluence runbook directory [linked]: list all services with runbooks and their last-modified date
- PagerDuty incident history — last 6 months [export attached]: all incidents by service

For each service that had incidents:
1. Does it have a runbook? (Yes / No / Outdated — last modified before the incident)
2. Did the incident type appear in the runbook? (Yes / No / Partial)
3. How many incidents in 6 months?

Produce:
- Coverage summary: X of Y incident-prone services have current runbooks
- Priority gap list (ranked by: incident frequency × lack of runbook coverage)
- Quick-win targets: services that had incidents where a simple runbook would have helped significantly
- Stale runbook list: runbooks not updated in 12+ months on services with recent incidents

Output as a Confluence page with an action table. Include estimated time to write each missing runbook so we can plan the backlog.