Background Jobs
Know when your queues are the problem, not just your requests
Two distinct signals, how long a job actually took to run and how long it sat waiting in queue before starting, each correlated the same way a request-latency spike already is.
Execution duration and queue latency are two different signals
How long a job actually took to run once it started, and how long it sat waiting in queue before that, are tracked as two distinct signals, not one blended number: a queue backing up behind a slow downstream dependency looks completely different from a job that's simply slow to execute once it starts, and conflating the two would hide exactly the distinction that matters when something's actually wrong.
Queue-wait latency is color-coded against real, documented thresholds, so a glance at the panel already tells you whether a queue is merely elevated or genuinely backed up, not just a raw number with no context for what's normal.
p95 queue-wait latency, per queue, not blended into one number.
Feeds the same rules Probable Cause already checks
A real background-job failure inside an incident's own window feeds directly into Probable Cause's background-job rule: a floor of 20% confidence just for a real failure existing, scaling up to full magnitude at 10 or more, since a failing job is often part of the spike itself, not a separate upstream cause with its own lead time to measure.