Telemetry

Skill pvnarp/agent-skills/skills/telemetry

Skills I use with Claude Code across my projects. Architecture, code review, testing, security, deployment, and more.

Install

npx -y skills add pvnarp/agent-skills --skill telemetry

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

1 stars1 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

Manages observability including error tracking, logging, metrics, and analytics. Covers instrumentation strategy, event definitions, and monitoring setup. Use when setting up monitoring, instrumenting events, or debugging production issues.

SKILL.md

2.7 KB, 562 tokens by cl100k_base, as published. Nobody here has run it

Telemetry & Observability

Three pillars: Errors (what broke), Metrics (how it's performing), Logs (what happened).

Error Tracking

Strategy

Use a dedicated error tracking service (Sentry, Bugsnag, Rollbar, etc.)
Capture unhandled exceptions automatically
Add breadcrumbs at key application events for context
Group errors by root cause, not by stack trace variation

Setup Pattern

1. Install SDK
2. Initialize early in application startup
3. Configure environment (dev/staging/production)
4. Set sample rate for performance tracing (10-20% is typical)
5. Upload source maps / debug symbols for readable stack traces

Breadcrumbs

Add context at key moments so error reports tell a story:

User actions (navigation, form submissions, key interactions)
State transitions (login, mode changes, configuration updates)
External calls (API requests, DB queries)

Metrics

Key Metrics to Track

Category	Metrics
Availability	Uptime, error rate, success rate
Performance	Response time (p50, p95, p99), throughput
Resources	CPU, memory, disk, connections
Business	Active users, key actions, conversion

Alerting Rules

Alert on symptoms, not causes (high error rate, not "disk at 80%")
Set meaningful thresholds based on actual baselines
Include runbook links in alerts
Avoid alert fatigue - every alert should require action

Logging

Levels

Level	When
ERROR	Something broke and needs attention
WARN	Something unexpected but handled
INFO	Significant application events
DEBUG	Detailed diagnostic info (dev/staging only)

Rules

Structured logging (JSON) in production for parseability
Include correlation IDs for request tracing
Never log secrets, PII, or full request bodies with sensitive data
Keep log volume manageable - noisy logs get ignored

Analytics Events

Define events that answer business questions:

EVENT: [name]
WHEN: [trigger condition]
PAYLOAD: [relevant data fields]
QUESTION IT ANSWERS: [what you learn from this]

Offline-First Pattern

Queue events locally when offline. Flush on connectivity. Batch inserts for efficiency. Dedup on the server if needed.

Phase Rollout

First: Error tracking (know when things break)
Next: Key metrics (know how things perform)
Then: Structured logging (know what happened)
Finally: Analytics (know how users behave)