observability

Designs correlated logs, metrics, and watchdogs to expose silent production failures.

1|Updated Aug 14, 2026
One-click install
npx skills add https://github.com/zhiyuan-zhang0206/Ava --skill observability-zhiyuan-zhang0206
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: observability
Source: https://github.com/zhiyuan-zhang0206/Ava/tree/main/ava_builtins/skills/ava-serious-engineering/practices/observability
Command: npx skills add https://github.com/zhiyuan-zhang0206/Ava --skill observability-zhiyuan-zhang0206

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Silent failures — suppressed exceptions, rolled-back batches, dead connections, stuck retries — leave systems looking healthy while data vanishes. This Skill provides principles, checklists, and anti-patterns for making every failure class visible, attributable, and locatable in minutes instead of days. ## Core Features & Use Cases - Failure Visibility Design: Ensures every exception path logs with correlation ids and increments honest counters, forbidding bare except blocks and contextlib.suppress patterns. - Metrics and Watchdog Contracts: Defines required signals for bounded resources (queue depth, overflow counts, retry rates) and watchdogs that alert on the absence of expected events like heartbeats and batch completions. - Use Case: When reviewing a background batch writer or SSE event queue, apply the checklist to verify drop counters increment at the point of failure, health checks exercise the real data path, and per-step timing answers which stage got slow. ## Quick Start Review my queue-based batch writer design using the observability skill and identify which failure classes lack visible signals.

Frequently Asked Questions about observability

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I make silent failures visible in background jobs?▼

Make every failure class emit a signal: increment a counter and write a structured log at the point of failure, never swallow exceptions with bare except or contextlib.suppress. Add watchdogs that alert when expected events like batch completions do not arrive on time.

What metrics should a queue or bounded buffer publish?▼

A bounded resource must publish depth or usage, an overflow count, and its drop policy, with an alert on sustained overflow. Retry loops need attempt counts, success-after-retry, and give-up counts as monotone counters with units.

Why is a liveness health check not enough for production services?▼

Liveness flags like is_connected can report True on a dead transport, letting processes write into dead sockets undetected. Health checks must perform a real round trip through the actual data path — a read, write, or publish — with a timeout.

How do I find which step is slow in a request pipeline?▼

Record per-step durations under a shared correlation id, or instrument spans, so each stage of the critical path is timed separately. Aggregate latency alone sends you to fix the wrong layer; step timing isolates the actual bottleneck.

When should observability be designed into a new system?▼

Observability is a design input, not an afterthought: before shipping, answer how you will know each failure class occurred, with a signal, an owner, and an alarm for absence. New components ship with at least one metric, one structured log line, and one watchdog.