Skip to main content

See a Laravel request's Sentry trace as a waterfall

Turn on Sentry tracing in your Laravel app with a sample rate of 1.0 and point the DSN at Buggregator. Every request then shows up as a waterfall of spans on your machine: database queries, cache, HTTP client calls and queue jobs on one timeline, with errors linked to the trace they happened in.

Steps

1. Point the SDK at Buggregator

One line in .env. Keep the number in the path: the data then goes to the default project, which the UI shows from the start.

dotenv
SENTRY_LARAVEL_DSN=http://sentry@127.0.0.1:8000/1

In Docker Compose, replace 127.0.0.1 with the Buggregator service name, for example buggregator.

2. Send every trace

Errors arrive as soon as the DSN is set. Traces are an SDK feature: switch them on in .env.

dotenv
SENTRY_TRACES_SAMPLE_RATE=1.0

The Laravel SDK then times each request and adds spans for database queries, Redis, caches (Laravel 11.11 or newer), HTTP client calls (Laravel 8.45 or newer), views, notifications and queue jobs. Symfony's SDK instruments its framework too. Plain sentry/sentry creates no transactions by itself: start them in your code with \Sentry\startTransaction(), as Sentry's custom instrumentation guide shows (https://docs.sentry.io/platforms/php/tracing/instrumentation/custom-instrumentation/).

3. Open the Traces tab

Load a page, then open the Sentry page and pick Traces. The tab appears once the current project has traces. Open a transaction to see every span on a timeline, each marked by type. The bar shows how long it took; failed spans are tagged.

4. Follow an error into its trace

Throw an exception in a request. The error shows a small waterfall of the request it happened in. Open the full trace to see every query and call around it.

Why it works

Buggregator stores what the Sentry SDK sends as traces: transactions with their spans. They are linked by trace: an error shows its trace, a trace lists the errors that happened in it, and logs link to their trace. A sample rate of 1.0 means the SDK sends every trace, not a sample.

Checked on with Buggregator v2.8.0

Setup in 60 seconds

No registration. No account. Start it and point your app at it.

1

Start Buggregator

One file, installed with one command. The web UI opens on port 8000. Prefer containers? Use the Docker tab.

$ curl -fsSL https://raw.githubusercontent.com/buggregator/server/master/scripts/install.sh | sh
$ HTTP_ADDR=127.0.0.1:8000 \
  SMTP_ADDR=127.0.0.1:1025 \
  VAR_DUMPER_ADDR=127.0.0.1:9912 \
  MONOLOG_ADDR=127.0.0.1:9913 \
  PROXY_ADDR=127.0.0.1:8080 \
  ~/.local/bin/buggregator

The script picks the file for your CPU: Intel/AMD or ARM.

One file for Linux, macOS and Windows, about 40 MB. Nothing else to install.

This run line keeps it on this computer. Without the *_ADDR settings it listens on all network interfaces →

Rather not run a script? Download the file yourself →

Runs on Windows, macOS and Linux, on Intel/AMD and ARM.

Prefer not to do it yourself? Your AI agent can set Buggregator up for you →