| name | investigate-orb |
| description | Use when diagnosing what happened on a field Orb, especially when given an orb_id tag, a service tag, an incident time, or symptoms involving health, connectivity, MCUs, attestation, updates, remote jobs, backend reporting, or signups. |
Investigate Orb
Overview
Investigate field Orbs from Datadog evidence. Build a UTC chronology, distinguish observations from inferences, and treat missing telemetry as an unknown rather than proof of health.
Establish Scope
Extract these values from the request:
orb_id:<orb_id>: required. Ask for it only when the context does not identify one Orb.service:<service_name>: optional. Use it as the starting service, not the investigation boundary.- Incident window: use the supplied bounds. Otherwise start at
1h and widen to 6h or 24h only when needed.
- Symptom: select related services from references/services.md.
Keep this skill's work read-only and limited to Datadog. Do not SSH into the Orb, run remote commands, restart services, create probes or downtimes, deploy software, or investigate the whole fleet unless the user explicitly expands the scope.
Use Pup
- If
dd-pup is available in the current skill catalog, read and follow it.
- Check for the CLI with
command -v pup.
- When both are available, use the skill's authentication guidance and the
pup CLI.
- When only the CLI is available, inspect
pup logs search --help before querying.
- When the CLI is absent, report the missing dependency. Do not install it without authorization.
Check authentication with . On authentication failure, follow when available; otherwise report the failure and the required login or permission. Never expose credentials or raw configuration.
