Queue & Job Monitoring

LaraBug 3.x tracks every background job your app dispatches — the class, the queue, the duration, whether it succeeded or failed, and the arguments. Horizon gives you a great live view, but LaraBug gives you the historical picture: percentile durations, failure rates over time, and stuck-job detection.

What gets tracked

Out of the box, after installation:

• Every queued job's lifecycle — dispatch, start, success, failure, retry
• Duration — wall-clock time from start to success or failure, captured on every job
• Payload — the serialised job arguments, with the DataFilter applied
• Queue and connection — which queue handled it, which driver (redis, database, sqs, ...)

No code changes needed. The SDK subscribes to Laravel's queue events (JobProcessing, JobProcessed, JobFailed) the moment the package boots.

Configuration

Open config/larabug.php and find the jobs section:

'jobs' => [
    'track_jobs' => env('LB_TRACK_JOBS', true),

    'track_completed' => env('LB_TRACK_COMPLETED', true),
    'track_failed' => env('LB_TRACK_FAILED', true),
    'track_processing' => env('LB_TRACK_PROCESSING', false),

    'sample_rate' => env('LB_SAMPLE_RATE', 1.0),

    'batch_size' => env('LB_BATCH_SIZE', 50),
    'flush_interval' => env('LB_FLUSH_INTERVAL', 30),

    'auto_batch_threshold' => env('LB_AUTO_BATCH_THRESHOLD', 10),
    'auto_batch_disable_threshold' => env('LB_AUTO_BATCH_DISABLE', 5),

    'ignore_jobs' => [
        // App\Jobs\NoisyJob::class,
    ],

    'ignore_queues' => [
        // 'default',
    ],

    'only_queues' => [
        // 'important',
    ],
],

The most common knobs:

• sample_rate — float between 0 and 1. Set to 0.1 to track 10% of successful jobs. Failures are always tracked at 100% regardless of this setting.
• ignore_jobs / ignore_queues — exclude specific job classes or queue names. Useful for noisy cron jobs or scheduled maintenance tasks.
• only_queues — whitelist mode. If set, only jobs on these queues get tracked.
• track_processing — off by default. Turn on if you want to see every job-start event, not just completions.

Dynamic batching

Under high load, sending a separate HTTP request for every job would drown your queue workers in network I/O. LaraBug detects high throughput automatically: when jobs-per-minute exceeds auto_batch_threshold, the SDK flips into batched mode and buffers events in memory, flushing every flush_interval seconds or when the buffer reaches batch_size.

When the rate drops below auto_batch_disable_threshold, it flips back to real-time immediate sends. You don't have to configure this — the defaults handle the common case.

Filtering what's captured

The DataFilter runs over every job payload before it leaves the worker, so serialised job arguments with keys matching the blacklist (password, token, auth, ...) get their values replaced with [FILTERED]. Large payloads are truncated at max_payload_size bytes (default 10KB) to keep ingest requests small.

Viewing in the dashboard

In your LaraBug project, the Queues section lists every queue your app has dispatched to, with live counts of pending, processing, completed, and failed jobs over the last 24 hours. Click into a queue to see an activity chart and drill into individual job executions.

The Jobs section groups by job class and shows per-class statistics: total executions, failure rate, average duration, 95th percentile, 99th percentile, and last run time. Great for catching the slow job that's starting to degrade.

Reporting SDK errors

If the SDK itself fails to send — bad network, rate limit, misconfigured keys — it swallows the error silently by default so it never breaks your job runner. If you want to see those failures:

'jobs' => [
    // ...
    'report_sdk_errors' => true,
    'report_buffer_errors' => true,
],

Recommended off in normal operation, on during initial rollout to debug connectivity issues.