agentsclimarketplace

Data observability and sla management

Skill vaquarkhan/data-engineering-agent-skills/skills/data-observability-and-sla-management

Production-grade Agent Skills for data engineering AI agents: 73 workflows, platform presets, safe backfill/replay, Kafka & Spark reliability, MCP observability, and VS Code/JetBrains installers.

Install
npx -y skills add vaquarkhan/data-engineering-agent-skills --skill data-observability-and-sla-management

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 21 stars21 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

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.

SKILL.md

2.4 KB, 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

  1. Define the service promises. Include:

    • freshness SLA
    • completeness expectations
    • acceptable latency
    • owner and escalation path

  2. Identify health signals. Common signals:

    • run success rate
    • task duration drift
    • volume anomalies
    • schema drift
    • consumer lag
    • data freshness

  3. Design alerts for actionability. Alerts should route to someone who can act, with enough context to investigate quickly.

  4. Capture run metadata and failure context.

  5. Review alert quality. Noisy alerts damage trust just as much as missing alerts.

  6. 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

RationalizationReality
"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

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.