LO

logging-best-practices

Provides best practices for implementing canonical log lines per request.

Install

mkdir -p .claude/skills/logging-best-practices && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/7983" && unzip -o skill.zip -d .claude/skills/logging-best-practices && rm skill.zip

Installs to .claude/skills/logging-best-practices

Activation

This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.

Logging best practices focused on wide events (canonical log lines) for powerful debugging and analytics
104 charsno explicit “when” trigger
Intermediate

Key capabilities

  • Emit wide events
  • Include business context
  • Propagate request IDs
  • Standardize log schemas
  • Implement middleware logging

How it works

The skill consolidates all request data into a single, context-rich JSON event emitted at request completion.

Inputs & outputs

You give it
Request lifecycle data
You get back
Canonical log line

When to use logging-best-practices

  • Design logging for new services
  • Review logging patterns in existing code
  • Implement canonical log lines for requests
  • Improve production debugging capability

About this skill

Logging Best Practices Skill

Version: 1.0.0

Purpose

This skill provides guidelines for implementing effective logging in applications. It focuses on wide events (also called canonical log lines) - a pattern where you emit a single, context-rich event per request per service, enabling powerful debugging and analytics.

When to Apply

Apply these guidelines when:

  • Writing or reviewing logging code
  • Adding console.log, logger.info, or similar
  • Designing logging strategy for new services
  • Setting up logging infrastructure

Core Principles

1. Wide Events (CRITICAL)

Emit one context-rich event per request per service. Instead of scattering log lines throughout your handler, consolidate everything into a single structured event emitted at request completion.

const wideEvent: Record<string, unknown> = {
  method: 'POST',
  path: '/checkout',
  requestId: c.get('requestId'),
  timestamp: new Date().toISOString(),
};

try {
  const user = await getUser(c.get('userId'));
  wideEvent.user = { id: user.id, subscription: user.subscription };

  const cart = await getCart(user.id);
  wideEvent.cart = { total_cents: cart.total, item_count: cart.items.length };

  wideEvent.status_code = 200;
  wideEvent.outcome = 'success';
  return c.json({ success: true });
} catch (error) {
  wideEvent.status_code = 500;
  wideEvent.outcome = 'error';
  wideEvent.error = { message: error.message, type: error.name };
  throw error;
} finally {
  wideEvent.duration_ms = Date.now() - startTime;
  logger.info(wideEvent);
}

2. High Cardinality & Dimensionality (CRITICAL)

Include fields with high cardinality (user IDs, request IDs - millions of unique values) and high dimensionality (many fields per event). This enables querying by specific users and answering questions you haven't anticipated yet.

3. Business Context (CRITICAL)

Always include business context: user subscription tier, cart value, feature flags, account age. The goal is to know "a premium customer couldn't complete a $2,499 purchase" not just "checkout failed."

4. Environment Characteristics (CRITICAL)

Include environment and deployment info in every event: commit hash, service version, region, instance ID. This enables correlating issues with deployments and identifying region-specific problems.

5. Single Logger (HIGH)

Use one logger instance configured at startup and import it everywhere. This ensures consistent formatting and automatic environment context.

6. Middleware Pattern (HIGH)

Use middleware to handle wide event infrastructure (timing, status, environment, emission). Handlers should only add business context.

7. Structure & Consistency (HIGH)

  • Use JSON format consistently
  • Maintain consistent field names across services
  • Simplify to two log levels: info and error
  • Never log unstructured strings

Anti-Patterns to Avoid

  1. Scattered logs: Multiple console.log() calls per request
  2. Multiple loggers: Different logger instances in different files
  3. Missing environment context: No commit hash or deployment info
  4. Missing business context: Logging technical details without user/business data
  5. Unstructured strings: console.log('something happened') instead of structured data
  6. Inconsistent schemas: Different field names across services

Guidelines

Wide Events (rules/wide-events.md)

  • Emit one wide event per service hop
  • Include all relevant context
  • Connect events with request ID
  • Emit at request completion in finally block

Context (rules/context.md)

  • Support high cardinality fields (user_id, request_id)
  • Include high dimensionality (many fields)
  • Always include business context
  • Always include environment characteristics (commit_hash, version, region)

Structure (rules/structure.md)

  • Use a single logger throughout the codebase
  • Use middleware for consistent wide events
  • Use JSON format
  • Maintain consistent schema
  • Simplify to info and error levels
  • Never log unstructured strings

Common Pitfalls (rules/pitfalls.md)

  • Avoid multiple log lines per request
  • Design for unknown unknowns
  • Always propagate request IDs across services

References:

When not to use it

  • Scattering multiple log lines per request
  • Logging unstructured strings

Prerequisites

Single logger instance

Limitations

  • Requires consistent field names across services
  • Simplifies to info and error levels only

How it compares

It shifts from scattered log lines to a single canonical log line per request, improving observability.

Compared to similar skills

logging-best-practices side by side with the closest alternatives in the catalog.

SkillInstallsUpdatedSafetyDifficulty
logging-best-practices (this skill)06moNo flagsIntermediate
langfuse76moNo flagsIntermediate
json-render-core32moNo flagsAdvanced
databuddy13moCautionIntermediate

Try saying

Example prompts that trigger this skill in your AI assistant.

You might also like

langfuse

davila7

Expert in Langfuse - the open-source LLM observability platform. Covers tracing, prompt management, evaluation, datasets, and integration with LangChain, LlamaIndex, and OpenAI. Essential for debugging, monitoring, and improving LLM applications in production. Use when: langfuse, llm observability, llm tracing, prompt management, llm evaluation.

743

json-render-core

vercel-labs

Core package for defining schemas, catalogs, and AI prompt generation for json-render. Use when working with @json-render/core, defining schemas, creating catalogs, or building JSON specs for UI/video generation.

323

databuddy

databuddy-analytics

Integrate Databuddy analytics into applications using the SDK or REST API. Use when implementing analytics tracking, feature flags, custom events, Web Vitals, error tracking, LLM observability, or querying analytics data programmatically.

110

sentry-cost-tuning

jeremylongshore

Optimize Sentry costs and event volume. Use when managing Sentry billing, reducing event volume, or optimizing quota usage. Trigger with phrases like "reduce sentry costs", "sentry billing", "sentry quota", "optimize sentry spend".

18

instantly-observability

jeremylongshore

Set up comprehensive observability for Instantly integrations with metrics, traces, and alerts. Use when implementing monitoring for Instantly operations, setting up dashboards, or configuring alerting for Instantly integration health. Trigger with phrases like "instantly monitoring", "instantly metrics", "instantly observability", "monitor instantly", "instantly alerts", "instantly tracing".

26

analytics-pipeline

dadbodgeoff

Real-time analytics with Redis counters, periodic PostgreSQL flush, and time-series aggregation. High-performance event tracking without database bottlenecks.

15

Search skills

Search the agent skills registry