# 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](/images/docs/jobs.png)

## 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](/images/docs/queues.png)

## Choosing which queues

```php 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

```php 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

```php 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.