Monitoring

What you see

• Per queue: success rate, throughput, average and 95th-percentile run time, and failed jobs, over 24 hours, 7, 30, or 90 days. Data goes back only as far as your plan keeps jobs. Metrics refresh every 30 seconds.
• A job list for each queue, refreshed every 10 seconds, and a Jobs page in the sidebar that lists jobs across all your team's queues
• Insights that flag recurring errors, spikes in failure rate or p95 run time, drops in throughput, repeated failures, and slow jobs

Drill into a job

• Name, ID, status, and when it was added, started, and finished
• Its data and options, such as delay, attempts, and backoff
• The error message and stack trace of a failed job
• Progress, while the job is active

Logs and return values come only from queues with a Redis connection. The SDK doesn't send them.

Filter and search

• Filter by status, priority, date range, duration, and whether a job has logs, a stack trace, or a retry. On the Jobs page, also filter by project, environment, and queue.
• Search by job name, or use name:, id:, or error: for a field and data.path:value for a value in the job's data. Quotes match exactly; a leading - excludes.
• Save a set of filters as a view, and copy a link to share it

PII redaction

• Redaction runs on Queuedash's side when a job arrives, before its data, options, and error message are written to the database. The SDK sends jobs as they are.
• Stack traces and logs are not redacted
• New projects start with redaction on and five built-in patterns: email addresses, phone numbers, Social Security numbers, credit card numbers, and IP addresses. A match becomes [REDACTED].
• Change it under the project's menu → Redaction settings: switch built-in patterns on or off, or add a rule for a regex or a field name
• Changes apply to jobs stored after you make them

Tips

• Watch a queue's metrics during deploys to spot regressions
• Use alerts to catch failures without watching the UI