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 the probable cause engine'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.
See it on your own data
Free plan included, no credit card required. New organizations start with 14 days of Business.
Get started freeGet