managing-flashduty

name	managing-flashduty
description	Use when working with Flashduty — flashDuty alerting and incident management covering alert routing, escalation policy configuration, on-call scheduling, collaboration channels, duty management, and integration setup. Use when configuring FlashDuty alert escalations, managing on-call rotations, setting up collaboration workflows, or reviewing incident resolution metrics.
connection_type	flashduty
preload	false

FlashDuty Management Skill

Manage FlashDuty alerting, escalation policies, on-call schedules, and collaboration workflows.

API Conventions

Authentication

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

Base URL

https://api.flashcat.cloud

Core Helper Function

#!/bin/bash

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

    if [ -n "$data" ]; then
        curl -s -X "$method" \
            -H "Authorization: Bearer $FLASHDUTY_API_KEY" \
            -H "Content-Type: application/json" \
            "https://api.flashcat.cloud${endpoint}" \
            -d "$data"
    else
        curl -s -X "$method" \
            -H "Authorization: Bearer $FLASHDUTY_API_KEY" \
            "https://api.flashcat.cloud${endpoint}"
    fi
}

Output Rules

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

Alert Management

List Active Alerts

fd_api GET "/v1/alerts?status=firing&limit=50" | jq '[.data[] | {
  id, title, severity, status,
  source, service, createdAt,
  assignee, escalationPolicy
}]'

Get Alert Details

fd_api GET "/v1/alerts/ALERT_ID" | jq '{
  title, severity, status, description,
  labels, annotations,
  timeline: [.events[] | {type, timestamp, actor}]
}'

Escalation Policies

List Escalation Policies

fd_api GET "/v1/escalation-policies" | jq '[.data[] | {
  id, name, description,
  steps: [.steps[] | {delayMinutes: .delay, targets: [.targets[] | .name]}]
}]'

Create Escalation Policy

fd_api POST "/v1/escalation-policies" '{
  "name": "Critical Service Escalation",
  "steps": [
    {"delay": 0, "targets": [{"type": "schedule", "id": "SCHEDULE_ID"}]},
    {"delay": 15, "targets": [{"type": "user", "id": "MANAGER_ID"}]}
  ]
}'

On-Call Schedules

List Schedules

fd_api GET "/v1/schedules" | jq '[.data[] | {id, name, timezone, currentOnCall: .currentShift.user}]'

Get Schedule Details

fd_api GET "/v1/schedules/SCHEDULE_ID" | jq '{
  name, timezone,
  rotations: [.layers[] | {name, rotationType, handoffTime, users: [.users[] | .name]}],
  currentOnCall: .currentShift
}'

Collaboration

List Channels

fd_api GET "/v1/channels" | jq '[.data[] | {id, name, type, integration, enabled}]'

Duty Management

Get Current On-Duty Users

fd_api GET "/v1/duties/current" | jq '[.data[] | {
  team, schedule: .scheduleName,
  user: .onDutyUser, startTime, endTime
}]'

Common Tasks

1. Configure escalation chains — set up multi-step escalation with appropriate delays
2. Manage on-call rotations — create and adjust rotation schedules across teams
3. Set up alert routing — connect monitoring tools and route by severity and service
4. Review duty coverage — verify all time slots have assigned on-call personnel
5. Analyze response times — track alert acknowledgment and resolution metrics

Output Format

Present results as a structured report:

Managing Flashduty 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

Shortcut	Counter	Why
"I'll skip discovery and check known resources"	Always run Phase 1 discovery first	Resource names change, new resources appear — assumed names cause errors
"The user only asked for a quick check"	Follow the full discovery → analysis flow	Quick checks miss critical issues; structured analysis catches silent failures
"Default configuration is probably fine"	Audit configuration explicitly	Defaults often leave logging, security, and optimization features disabled
"Metrics aren't needed for this"	Always check relevant metrics when available	API/CLI responses show current state; metrics reveal trends and intermittent issues
"I don't have access to that"	Try the command and report the actual error	Assumed permission failures prevent useful investigation; actual errors are informative