error-tracking

Enforces .NET observability rules for exception handling, structured logging, metrics, and tracing.

7|3|Updated Sep 23, 2025
One-click install
npx skills add https://github.com/islamu-ngo/Event --skill error-tracking-islamu-ngo
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: error-tracking
Source: https://github.com/islamu-ngo/Event/tree/main/.agents/skills/error-tracking
Command: npx skills add https://github.com/islamu-ngo/Event --skill error-tracking-islamu-ngo

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? .NET services often ship with inconsistent error responses, swallowed exceptions, and fragmented telemetry, making production incidents hard to diagnose. This Skill provides a single set of guardrails for exception handling, structured logging, metrics, and distributed tracing so errors remain observable end to end. ## Core Features & Use Cases - Standardized Error Responses: Enforces RFC 7807 ProblemDetails with traceId, correlationId, and timestamp extensions, plus a chained IExceptionHandler pipeline for validation and global errors. - Observability Stack Guidance: Covers OpenTelemetry traces, Prometheus metrics with cardinality guardrails, and Loki structured logging with label and field rules. - Use Case: When adding a new API endpoint or MediatR handler, load this Skill to ensure exceptions flow through the correct handler chain, logs include correlation context, and business metrics are emitted with proper tenant tags. ## Quick Start Ask the AI to review your .NET exception handling and logging changes against the error-tracking observability rules before committing.

Frequently Asked Questions about error-tracking

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

FAQPage Schema
How do I implement centralized exception handling in ASP.NET Core?▼

Use a chained IExceptionHandler setup: a ValidationExceptionHandler returning 400 for validation errors, followed by a GlobalExceptionHandler returning 500 in production. Each handler returns true to stop the chain, and all responses use RFC 7807 ProblemDetails.

What should a standard API error response include?▼

Use RFC 7807 ProblemDetails with type, title, status, detail, and instance, plus extensions for traceId, correlationId, timestamp, and a field-level errors dictionary for validation failures. Never expose raw exception internals in production.

How do I add correlation IDs to logs and responses in .NET?▼

Use middleware that reads X-Correlation-ID or X-Request-ID from inbound requests, generates a GUID if absent, pushes it to Serilog LogContext, and adds it to response headers so logs and ProblemDetails stay correlated.

Does this observability setup use Sentry for error tracking?▼

No, Sentry is explicitly not used. The stack relies on OpenTelemetry for traces and metrics, Prometheus scraping a /metrics endpoint, and Loki for structured logs, with Grafana for dashboards.

Why are my handled exceptions missing logs and metrics in .NET 10?▼

In .NET 10, once an IExceptionHandler returns true, handled exceptions may suppress logs, metrics, and events by default. Treat this as an explicit observability decision and configure SuppressDiagnosticsCallback on UseExceptionHandler if diagnostics are needed.

What are the cardinality limits for Prometheus metric labels?▼

Keep label sets small and stable: use route templates instead of raw URLs, never label metrics with unbounded user input, and limit dimensions to service name, environment, bounded tenant, and operation type.