observability-checker

Verify OpenTelemetry-based services for complete four-pillar observability.

3|2|Updated Jan 23, 2026
One-click install
npx skills add https://github.com/robotijn/ctoc --skill observability-checker
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: observability-checker
Source: https://github.com/robotijn/ctoc/tree/main/skills/specialized/observability-checker
Command: npx skills add https://github.com/robotijn/ctoc --skill observability-checker

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Production services often lack complete, conformant observability, leaving teams unable to diagnose outages, latency regressions, or errors without redeploying, leading to extended mean time to resolution and end-user impact.

Core Features & Use Cases

  • Four-pillar validation: Checks traces, metrics, logs, and continuous profiling for completeness, OpenTelemetry semantic convention conformance, and cross-pillar correlation via trace IDs.
  • Risk detection: Flags high-cardinality metric labels that cause memory bombs, PII/secrets in logs, missing SLO/error budget definitions, and absent health/readiness probes.
  • Use Case: A team preparing to launch a new payment microservice can run this skill to verify all HTTP, database, and queue boundaries are instrumented with OTel spans, logs carry trace context, and latency/availability SLOs are defined before release.

Quick Start

Use the observability-checker skill to audit your payment microservice's observability setup for missing trace instrumentation, unstructured logs, high-cardinality metrics, and undefined SLOs.

Frequently Asked Questions about observability-checker

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

FAQPage Schema
How do I check my OpenTelemetry traces, metrics, and logs for missing instrumentation?

Verify observability across traces, metrics, logs, and profiling by checking boundary instrumentation, semantic convention conformance, and cross-pillar trace ID correlation to eliminate silent monitoring gaps.

What causes high-cardinality metric labels to create memory bombs in production observability setups?

High-cardinality metric labels cause memory bombs when unbounded label values consume excessive memory, which an observability audit can flag to enforce metric cardinality discipline before deployment.

How do I prevent PII leakage in structured application logs?

Prevent PII leakage in structured logs by auditing log payloads against security policies, flagging sensitive data exposure, and ensuring trace context is attached without revealing personal information.

Can I validate SLO and error budget definitions before launching a microservice?

Validate SLO and error budget definitions before launch by checking that latency and availability SLOs are explicitly configured alongside health and readiness probes for rapid incident diagnosis.

Does observability-checker work with codebases using OpenTelemetry for telemetry collection?

It works with codebases using OpenTelemetry for telemetry collection, verifying HTTP, database, and queue boundaries are instrumented with OTel spans and logs carry trace context for cross-pillar correlation.

What is the best way to ensure continuous profiling is included in my observability strategy?

Include continuous profiling in your observability strategy by validating all four pillars—traces, metrics, logs, and profiling—for completeness, ensuring cross-pillar correlation via trace IDs for rapid incident diagnosis.