Capturing Exceptions

Once the package is installed and added to the log stack, exception capture is fully automatic. Laravel's default exception handler routes every unhandled throwable through the larabug log channel, which forwards it to the ingest endpoint along with the full request context.

You don't have to call anything. You don't have to change your App\Exceptions\Handler. You don't have to wrap your controllers.

But sometimes you want more control.

Manual capture

Call report() anywhere in your app to send a specific throwable:

try {
    $this->riskyOperation();
} catch (\Throwable $e) {
    report($e);

    return response()->json(['error' => 'Something went wrong'], 500);
}

report() is Laravel's standard helper and already routes through the log channel, so LaraBug catches it without any extra work.

Adding custom context

Sometimes the stack trace and request data aren't enough — you want to attach application-specific breadcrumbs like the feature flag state, the tenant ID, or the pipeline step you were running.

Use LaraBug::context() to add fields that get merged into the next captured exception:

use LaraBug\Facade as LaraBug;

LaraBug::context([
    'tenant_id' => $tenant->id,
    'feature_flags' => $flags->active(),
    'pipeline_step' => 'validate_payment',
]);

try {
    $this->processPayment($request);
} catch (\Throwable $e) {
    report($e);
    throw $e;
}

Context is per-request and one-shot — it gets attached to the next captured exception and then cleared. That keeps the data relevant to the error and avoids leaking state across requests.

Attaching user information

See User Context for how LaraBug picks up the currently authenticated user automatically, and how to customise which fields get sent.

What's in the payload

Every captured exception includes:

• Class, message, file, line, stack trace
• Request context — URL, method, headers, parameters, session, cookies
• Server environment — PHP version, server software, user agent
• User — if authenticated, pulled from auth()->user()
• Code context — the lines of source around the throw point (lines_count in config)
• Custom context — anything you added via LaraBug::context()
• Release — project_version from config, for grouping by deploy

Before the payload leaves your server, the DataFilter runs over it and scrubs any field whose key matches the blacklist. Passwords and tokens never leave your infrastructure.

Silencing specific exceptions

Three options, least to most aggressive:

1. except config list — add the exception class to config('larabug.except'). LaraBug drops it before serialising anything.
2. Laravel's dontReport list — add the class to $dontReport in App\Exceptions\Handler. Laravel drops it before LaraBug even sees it.
3. Don't log it — don't call report() and don't let it bubble up to the exception handler. You're on your own.

Next

• User Context — attach the right user data
• Queue & Job Monitoring — the same pipeline for background jobs