Managing Zenduty

Zenduty Incident Management Skill

Manage Zenduty incidents, SLA tracking, on-call schedules, escalation policies, and postmortems.

API Conventions

Authentication

All API calls use the Authorization: Token XXXXXX header — injected automatically. Never hardcode tokens.

Base URL

https://www.zenduty.com/api

Core Helper Function

#!/bin/bash

zd_api() {
    local method="$1"
    local endpoint="$2"
    local data="${3:-}"

    if [ -n "$data" ]; then
        curl -s -X "$method" \
            -H "Authorization: Token $ZENDUTY_API_KEY" \
            -H "Content-Type: application/json" \
            "https://www.zenduty.com/api${endpoint}" \
            -d "$data"
    else
        curl -s -X "$method" \
            -H "Authorization: Token $ZENDUTY_API_KEY" \
            "https://www.zenduty.com/api${endpoint}"
    fi
}

Output Rules

• TOKEN EFFICIENCY: Extract only needed fields with jq
• Target ≤50 lines per script output

Incident Management

List Active Incidents

zd_api GET "/incidents/?status=1&team_id=TEAM_ID" | jq '[.results[] | {
  unique_id, title, status, urgency,
  service: .service.name,
  assigned_to: [.assigned_to[] | .username],
  created, acknowledged, resolved
}]'

Get Incident Details

zd_api GET "/incidents/INCIDENT_ID/" | jq '{
  title, status, urgency, summary,
  service: .service.name,
  escalation_policy: .escalation_policy.name,
  sla: {breached: .sla_breached, response_time: .sla_response_time},
  timeline: [.logs[] | {action, timestamp, user}]
}'

SLA Tracking

Get SLA Policies

zd_api GET "/account/sla/" | jq '[.[] | {
  id, name, description,
  acknowledge_time, resolve_time,
  is_active, escalation_policy
}]'

Check SLA Compliance

zd_api GET "/analytics/sla/?period=30d" | jq '{
  period: "30 days",
  totalIncidents: .total,
  slaCompliant: .compliant,
  slaBreach: .breached,
  complianceRate: .compliance_percentage,
  avgResponseTime: .avg_response_time,
  avgResolveTime: .avg_resolve_time
}'

Escalation Policies

List Escalation Policies

zd_api GET "/account/teams/TEAM_ID/escalation_policies/" | jq '[.[] | {
  unique_id, name, description,
  rules: [.rules[] | {delay: .delay, targets: [.targets[] | .target_type]}]
}]'

On-Call Schedules

Get Current On-Call

zd_api GET "/account/teams/TEAM_ID/schedules/" | jq '[.[] | {
  unique_id, name, timezone,
  current_on_call: .on_call_user.username,
  layers: [.layers[] | {name, rotation_type, users: [.users[] | .username]}]
}]'

Postmortems

List Postmortems

zd_api GET "/postmortems/?team_id=TEAM_ID" | jq '[.results[] | {
  id, title, incident: .incident.title,
  created, status,
  action_items: [.action_items[] | {description, assignee, status}]
}]'

Create Postmortem

zd_api POST "/postmortems/" '{
  "incident": "INCIDENT_ID",
  "title": "Postmortem: Payment Service Outage",
  "team": "TEAM_ID"
}'

Services

List Services

zd_api GET "/account/teams/TEAM_ID/services/" | jq '[.[] | {
  unique_id, name, description,
  escalation_policy: .escalation_policy.name,
  sla: .sla.name,
  status: .status
}]'

Common Tasks

1. Track SLA compliance — monitor acknowledgment and resolution time against SLA targets
2. Generate postmortems — create structured post-incident reports with action items
3. Configure escalation — build multi-tier escalation policies with appropriate delays
4. Manage on-call rotations — set up schedules with layers and override support
5. Analyze incident trends — review incident volume, severity distribution, and team workload

Output Format

Present results as a structured report:

Managing Zenduty Report
═══════════════════════
Resources discovered: [count]

Resource       Status    Key Metric    Issues
──────────────────────────────────────────────
[name]         [ok/warn] [value]       [findings]

Summary: [total] resources | [ok] healthy | [warn] warnings | [crit] critical
Action Items: [list of prioritized findings]

Target ≤50 lines of output. Use tables for multi-resource comparisons.

Anti-Hallucination Rules

1. NEVER assume resource names — always discover via CLI/API in Phase 1 before referencing in Phase 2.
2. NEVER fabricate metric names or dimensions — verify against the service documentation or --help output.
3. NEVER mix CLI commands between service versions — confirm which version/API you are targeting.
4. ALWAYS use the discovery → verify → analyze chain — every resource referenced must have been discovered first.
5. ALWAYS handle empty results gracefully — an empty response is valid data, not an error to retry.

Counter-Rationalizations