Queues and jobs

The client reports queue work as well as exceptions, which is what fills the queue pages in the panel: what is waiting, what is running, what failed, and how long a job takes.

The Jobs page in the panel: each job class with its runs, failures, average and p95

What is tracked

Key	Environment variable	Default	What it does
`jobs.track_jobs`	`LB_TRACK_JOBS`	`true`	The switch for all of it.
`jobs.track_failed`	`LB_TRACK_FAILED`	`true`	Failed jobs.
`jobs.track_completed`	`LB_TRACK_COMPLETED`	`true`	Completed jobs, which is what makes throughput and duration possible.
`jobs.track_processing`	`LB_TRACK_PROCESSING`	`false`	A report the moment a job starts. Off by default: it doubles the events for a number you can infer.

Completed jobs are the expensive ones. On an application that runs a million jobs a month they are a million events, so if you only want to know about failures, turn track_completed off and keep track_failed.

The Queues page in the panel: each queue with what is pending, processing and failed, and the day's activity

Choosing which queues

config/larabug.php

'only_queues' => array_filter(explode(',', env('LB_ONLY_QUEUES', ''))),
'ignore_queues' => array_filter(explode(',', env('LB_IGNORE_QUEUES', ''))),
'ignore_jobs' => [],

only_queues is a whitelist and wins where both are set. ignore_jobs takes class names, for the one job that runs every minute and tells you nothing.

Sampling

config/larabug.php

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

A rate of 0.1 reports one job in ten. Durations and throughput stay representative, the event count drops by nine tenths, and a failure is still a failure: sampling applies to the volume, not to the thing you are watching for.

Batching

Reports are batched rather than sent one at a time, and the batch adapts to load.

Key	Default	What it does
`batch_size`	`50`	Reports per request.
`flush_interval`	`30`	Seconds before a partial batch is sent anyway.
`auto_batch_threshold`	`10`	Jobs per second before batching turns itself up.
`auto_batch_disable_threshold`	`5`	Jobs per second before it turns itself back down.
`auto_batch_cooldown`	`5`	Seconds it waits before doing either.
`max_retries`	`3`	Attempts before a batch is dropped.
`max_payload_size`	`10000`	Bytes of job payload kept per report.

The defaults hold on a busy queue. Raise batch_size and flush_interval together if you would rather trade freshness for fewer requests.

Tracking one job on purpose

With track_jobs off, or where you want a job followed that would otherwise be sampled out:

PHP

dispatch_tracked(new GenerateMonthlyInvoices($team));

The helper sets trackInLaraBug on the job and dispatches it, which you can also do yourself:

PHP

$job = new GenerateMonthlyInvoices($team);
$job->trackInLaraBug = true;

dispatch($job);

The client's own errors

config/larabug.php

'report_sdk_errors' => env('LB_REPORT_SDK_ERRORS', false),
'report_buffer_errors' => env('LB_REPORT_BUFFER_ERRORS', false),

Both off by default. Turn them on while you are debugging why nothing is arriving, and off again afterwards: a client that reports its own failures to the service it cannot reach is a loop you do not want on a bad day.

Previous Queries Next Scheduled tasks