Data observability and sla management
Skill vaquarkhan/data-engineering-agent-skills/skills/data-observability-and-sla-management
Guides agents through data observability and service-level management. Use when defining or improving freshness, completeness, anomaly detection, alerting, lag tracking, run metadata, and ownership for production data products.From its SKILL.md
npx -y skills add vaquarkhan/data-engineering-agent-skills --skill data-observability-and-sla-managementAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
SKILL.md
2.4 KB, 460 tokens by cl100k_base, as published. Nobody here has run it
Data Observability And SLA Management
Overview
Use this skill when the pipeline must be operated as a service, not just executed as code. It helps agents define what healthy looks like and how teams know when the system drifts away from that state.
When to Use
- launching or hardening a production data product
- defining freshness or completeness SLAs
- improving alerting and anomaly detection
- adding operational metadata and health visibility
- reducing noisy or low-signal incident response
- designing resilience drills with explicit alert and recovery evidence
Workflow
-
Define the service promises. Include:
- freshness SLA
- completeness expectations
- acceptable latency
- owner and escalation path
-
Identify health signals. Common signals:
- run success rate
- task duration drift
- volume anomalies
- schema drift
- consumer lag
- data freshness
-
Design alerts for actionability. Alerts should route to someone who can act, with enough context to investigate quickly.
-
Capture run metadata and failure context.
-
Review alert quality. Noisy alerts damage trust just as much as missing alerts.
-
Pair health signals with resilience drills when recovery behavior matters. Load
references/data-resiliency-testing-patterns.mdwhen the team must prove restart, retry, backlog, or failover behavior under controlled failure.
Common Rationalizations
| Rationalization | Reality |
|---|---|
| "The scheduler already tells us if it fails." | Task failure alone does not measure stale, partial, or bad data. |
| "More alerts are safer." | Alert fatigue makes real incidents easier to miss. |
| "The business will tell us if something is wrong." | That means the system failed before the team noticed. |
Red Flags
- no named owner or escalation path
- freshness is assumed but not measured
- alerts fire without run context or impact clues
- anomaly detection exists with no response playbook
Verification
- SLAs and ownership are defined
- Health signals exist for freshness, completeness, and reliability
- Alerts are actionable and routed correctly
- Run metadata supports fast diagnosis
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.