logging-best-practices▌
boristane/agent-skills · updated Apr 8, 2026
Structured logging pattern using wide events for comprehensive request-level debugging and analytics.
- ›Consolidates all request context into a single JSON event per service, emitted at completion, rather than scattering log lines throughout handlers
- ›Emphasizes high cardinality fields (user IDs, request IDs) and high dimensionality (many fields per event) to enable flexible querying and correlation across services
- ›Requires business context in every event: subscription tier, cart value,
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:
infoanderror - Never log unstructured strings
Anti-Patterns to Avoid
- Scattered logs: Multiple console.log() calls per request
- Multiple loggers: Different logger instances in different files
- Missing environment context: No commit hash or deployment info
- Missing business context: Logging technical details without user/business data
- Unstructured strings:
console.log('something happened')instead of structured data - 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:
Ratings
4.5★★★★★10 reviews- ★★★★★Shikha Mishra· Oct 10, 2024
logging-best-practices is among the better-maintained entries we tried; worth keeping pinned for repeat workflows.
- ★★★★★Piyush G· Sep 9, 2024
Keeps context tight: logging-best-practices is the kind of skill you can hand to a new teammate without a long onboarding doc.
- ★★★★★Chaitanya Patil· Aug 8, 2024
Registry listing for logging-best-practices matched our evaluation — installs cleanly and behaves as described in the markdown.
- ★★★★★Sakshi Patil· Jul 7, 2024
logging-best-practices reduced setup friction for our internal harness; good balance of opinion and flexibility.
- ★★★★★Ganesh Mohane· Jun 6, 2024
I recommend logging-best-practices for anyone iterating fast on agent tooling; clear intent and a small, reviewable surface area.
- ★★★★★Oshnikdeep· May 5, 2024
Useful defaults in logging-best-practices — fewer surprises than typical one-off scripts, and it plays nicely with `npx skills` flows.
- ★★★★★Dhruvi Jain· Apr 4, 2024
logging-best-practices has been reliable in day-to-day use. Documentation quality is above average for community skills.
- ★★★★★Rahul Santra· Mar 3, 2024
Solid pick for teams standardizing on skills: logging-best-practices is focused, and the summary matches what you get after install.
- ★★★★★Pratham Ware· Feb 2, 2024
We added logging-best-practices from the explainx registry; install was straightforward and the SKILL.md answered most questions upfront.
- ★★★★★Yash Thakker· Jan 1, 2024
logging-best-practices fits our agent workflows well — practical, well scoped, and easy to wire into existing repos.