Troubleshooting

Common issues and how to fix them, in rough order of likelihood.

Events aren't showing up in the dashboard

Check the environment. By default, LaraBug only reports in production. Your local and staging servers are silent unless you add them:

// config/larabug.php
'environments' => [
    'production',
    'staging',
],

Check the credentials. Run:

php artisan tinker
>>> config('larabug.login_key')
>>> config('larabug.project_key')

Both should return non-empty strings. If either returns null or an empty string, your .env isn't loaded or config:cache is stale. Try php artisan config:clear.

Check the network. From the server that should be reporting:

curl -I https://www.larabug.com/api/log

You should get a response (probably 405 Method Not Allowed because curl -I uses HEAD). If it times out, your server can't reach our API — check DNS, firewall, and outbound proxy settings.

Check the dedupe window. If you fired the same exception twice in the last 60 seconds, the second one is deliberately dropped. Change the URL, change the line, or set sleep to 0 in config temporarily.

"Driver [larabug] is not supported"

This means your logging.php config references the larabug driver before the LaraBug\ServiceProvider has a chance to register it. Almost always caused by a stale config cache:

php artisan config:clear
php artisan cache:clear

If that doesn't fix it, make sure the service provider is registered. It auto-registers via Laravel's package discovery in normal installs, but if you have dont-discover set in composer.json, add LaraBug\ServiceProvider::class manually to config/app.php's providers array.

Test command works, real exceptions don't

You set up larabug:test and it succeeded, but real exceptions from your controllers never show up. Two likely causes:

1. Your exception handler is eating them. Open App\Exceptions\Handler and look for exceptions in the $dontReport array — they get silenced for LaraBug too. Either remove the entry or call report($e) manually before the exception is caught.

2. You're returning responses instead of throwing. return response()->json(['error' => ...], 500); doesn't trigger the exception handler — nothing is thrown. If you want LaraBug to see it, wrap the failure in an actual throwable:

try {
    $this->riskyOperation();
} catch (\Throwable $e) {
    report($e);
    return response()->json(['error' => 'Something went wrong'], 500);
}

Queue jobs aren't being tracked

Check jobs.track_jobs is true. It's the master switch:

'jobs' => [
    'track_jobs' => true,
    // ...
],

Check the queue driver. LaraBug subscribes to Laravel's queue events. If your app uses a queue system that bypasses those events (custom driver, direct Redis pushes), nothing fires.

Check ignore_jobs / ignore_queues. If your job class or queue name is in the blacklist, it's dropped. Print the relevant config values and verify:

php artisan tinker
>>> config('larabug.jobs')

Payloads look truncated

Request bodies and job payloads are capped at max_payload_size (default 10KB). Large uploads, long JSON bodies, and big job arguments get trimmed with a ... marker. Bump the limit in config if you need more:

'jobs' => [
    'max_payload_size' => 50000,
],

Be mindful — very large payloads slow down ingest and bloat your dashboard. Usually the right fix is to shorten the payload, not raise the cap.

Still stuck?

Open an issue on github.com/LaraBug/LaraBug with:

• Your Laravel version (php artisan --version)
• Your PHP version (php -v)
• Your composer.json excerpt showing the larabug version
• The exact error message or the symptom
• What you've already tried

We typically respond within one business day.