User Context

Knowing which user hit an error is often the difference between "we'll fix that next sprint" and "we'll fix that right now". LaraBug attaches user information to every captured exception automatically — as long as a user is authenticated at the time the error fires.

Default behaviour

If your User model extends Illuminate\Foundation\Auth\User (which is Laravel's default), LaraBug calls $user->toArray() and attaches the result to the exception payload.

That gives you id, email, name, created_at, and any other visible attributes — but it also attaches anything else in $hidden has excluded, which is usually the right thing. Hidden fields like password and remember_token stay hidden.

Controlling what gets sent

For anything more than the default toArray() output, implement the Larabugable interface on your User model:

use LaraBug\Concerns\Larabugable;

class User extends Authenticatable implements Larabugable
{
    public function toLarabug(): array
    {
        return [
            'id' => $this->id,
            'email' => $this->email,
            'plan' => $this->currentPlan()?->slug,
            'is_admin' => (bool) $this->is_admin,
        ];
    }
}

When the interface is present, LaraBug calls toLarabug() instead of toArray(). This lets you include computed fields (plan, role, tenant) and exclude anything you don't want in the dashboard.

Multi-tenant apps

If you have a notion of tenant or organisation that isn't the user, attach it as custom context right before the risky operation:

LaraBug::context([
    'tenant_id' => $tenant->id,
    'tenant_name' => $tenant->name,
]);

See Capturing Exceptions → Adding custom context for the full pattern.

GDPR & privacy

User data is subject to the same filtering pipeline as everything else. If a field in your User model happens to have a key name matching the blacklist (*password*, *token*, *secret*, *email* in the default list), its value gets replaced with [FILTERED].

The default blacklist includes *email*. If you want emails in the dashboard, either remove it from the blacklist in config('larabug.blacklist') or implement toLarabug() and put the email under a different key like contact_email — the wildcard match is exact on the key name.

Never put raw passwords or API tokens into your user array. The filter should catch them, but the safest thing is to not put them there in the first place.