Should I use traces to debug production incidents?

Yes—traces are often one of the best tools for debugging production incidents, especially when the problem involves requests flowing through multiple services.

Traces are especially useful when:

• You need to follow a single request end-to-end across services
• The issue is latency, timeouts, retries, or fan-out behavior
• Logs alone don’t show where time is being spent
• You want to identify which downstream call is failing or slow

Traces are less useful when:

• The incident is a purely local bug in one process and logs/metrics already show the cause
• You need very high-volume, aggregate signals — metrics are usually better for that
• You’re looking for exact error details; logs often provide the clearest message/stack trace

Practical rule of thumb

Use:

• Metrics to detect and scope the incident
• Traces to pinpoint where the request path is breaking or slowing down
• Logs to get the exact error context

In production, a good approach is:

• Keep tracing on for critical services
• Use sampling to control cost and volume
• Ensure trace IDs are correlated with logs
• Make sure sensitive data isn’t captured in spans

If you want, I can also give you a decision tree for when to use logs vs metrics vs traces during an incident.