Add error tracking to your Laravel app in two minutes

This is the whole setup, start to finish. No agent, no YAML safari — two commands and an env var. By the end you'll have a real exception grouped and traced in your dashboard, plus automatic N+1 and slow-query detection you didn't have to configure.

What you'll need

• A Laravel app (Laravel 10, 11, or 12) you can run composer and artisan against.
• Composer and a PHP version your Laravel version supports.
• About two minutes.

That's it — there's no agent to install on your server and no separate daemon to keep alive. Lookout's SDK reports over plain HTTP, so anything that can make an outbound request can send events.

Before you start

Create a free Starter project at the dashboard (10,000 events/month, no credit card) and copy its project API key from the project's settings. Keep it handy — you'll paste it in one place.

Step 1 — Install the package

From your Laravel app root (the directory with artisan):

composer require lookout/tracing
php artisan lookout:install

composer require pulls the package into vendor/ and Laravel auto-discovers the service provider — there's nothing to register by hand. lookout:install is a short wizard that writes the connection settings into your .env.

Step 2 — Point it at your project

The installer can take a DSN, but the clearest way to configure it is two plain env values:

LOOKOUT_LARAVEL=true
LOOKOUT_API_KEY=your-project-api-key
LOOKOUT_URL=https://your-lookout-host.example.com

If you run config:cache in your deploy, rebuild it now (php artisan config:clear in development). That's the entire integration — unhandled exceptions are already being reported.

How it works under the hood

It's worth knowing what just happened, because it explains why setup is so short. Laravel funnels every uncaught exception through its exception handler, which has two jobs: report (log it / send it somewhere) and render (turn it into an HTTP response). The Lookout service provider hooks the report side, so every reportable exception becomes an event — captured before Laravel renders a 500 to your user. Because ingest is plain HTTP/JSON, there's no agent process and nothing to keep running alongside your app.

Step 3 — Throw a test error

Add a throwaway route and hit it once:

Route::get('/lookout-test', function () {
    throw new RuntimeException('Hello from Lookout');
});

Load /lookout-test, then delete the route. Within a second or two the exception shows up in your project's dashboard — message, level, exception class, stack trace, and the request that triggered it.

What you get for free, automatically

Open the issue Lookout just created and you'll see more than a stack trace:

• Grouping by fingerprint. Refresh that broken route ten times and you get one issue with a count of ten, not ten rows of the same thing.
• Query and N+1 detection. Requests that fan out into repeated near-identical queries get flagged as N+1s; slow queries are surfaced on their own. You didn't configure anything for this.
• Blade and job traces. View renders and queued jobs show up in the trace, so a slow page or a failing job tells you where, not just that.
• Request context. The URL, HTTP method, and (optionally) the authenticated user travel with the error, so you can reproduce it instead of guessing.

Step 4 — Turn a flood into one alert

Errors are only half the job; you want to hear about the right ones. In the project's alert rules, set a threshold over a 1h or 24h window and pick a channel (Email or Slack). Now a spike pages you once — not on every single event.

Verifying it's working in production

The test route proves your local setup. To confirm production is reporting:

1. Deploy with the three env values set (and config:cache rebuilt if you cache config).
2. Trigger any real, harmless error path — or temporarily re-add the test route behind auth.
3. Watch it appear in the dashboard, then confirm new errors keep flowing as traffic comes through.

Once real traffic is moving, the N+1 and slow-query flags start appearing on their own — those are usually the first genuinely useful things you'll see.

Troubleshooting: nothing showing up?

If the test exception doesn't land, run through this short checklist:

• Config cache. If you cached config before setting the env values, run php artisan config:clear (dev) or rebuild config:cache (prod).
• The API key. Make sure LOOKOUT_API_KEY is the project key from settings, pasted without quotes or stray whitespace.
• LOOKOUT_LARAVEL=true. This switch turns the integration on; without it, nothing reports.
• Outbound HTTP. The app needs to reach LOOKOUT_URL. Behind a strict egress firewall, allow that host.
• It actually threw. Confirm the route really raised an unhandled exception (a caught-and-swallowed exception won't report unless you report it explicitly).

Environment variable reference

Optional: request performance and traces

For full request-timing traces, add the performance middleware to your web group and register lookoutTracing.continueTrace on the routes you want stitched into a single trace. Publish the config first if you want to see every knob:

php artisan vendor:publish --tag=lookout-tracing-config

The package README covers breadcrumbs, "glows" (extra context attached to an error), user metadata, and Guzzle/HTTP propagation when you're ready to go deeper.

FAQ

Do I need an agent or daemon? No. The SDK reports over HTTP; there's nothing extra to run.

Will it slow down my app? Reporting is lightweight and happens out of the critical path. The detectors watch queries that already ran — they don't add queries.

Is the free tier really enough to try it for real? Yes — 10,000 events a month and one project, no credit card. That's enough to put genuine production traffic through and decide with your own data.

What else can it track? Beyond exceptions: N+1 and slow queries, Blade views, queued jobs, and outbound HTTP. The complete guide to Laravel error tracking covers the full picture and how to choose a tool.

That's it

Two commands, one API key, and a test exception. The free Starter tier is enough to run real production traffic through, so the honest next step is to point it at something you actually ship and see what it catches.

Create your free project and have your first grouped, traced error before your coffee's cold.