| name | data-observability-and-sla-management |
| description | 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. |
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.md when 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
