docs · by hand · laravel from sentry

Laravel errors with the Sentry SDK you already have.

Change the DSN and the exceptions your Laravel app already reports arrive in Vinktar. Then add product events with the native PHP SDK, on the same user id, so an error sits next to what the person was doing. Checked on sentry-laravel 4.28.0 with Laravel 13.34 and PHP 8.5.

1. The DSN

SENTRY_LARAVEL_DSN=https://abc123@o12345.ingest.sentry.io/451

SENTRY_LARAVEL_DSN=https://vnk_pk_YOUR_KEY@in.vinktar.com/YOUR_PROJECT_ID

The key is the project's public write key and the number is the project id. The finished DSN is on the project's Connect page under Manual, and an agent gets it from get_project_keys. config/sentry.php reads SENTRY_LARAVEL_DSN first and SENTRY_DSN after it. On Laravel 11 and later the Integration::handles line is what reports an unhandled request exception; without it sentry:test and captureMessage work and a route that throws sends nothing.

check it worked

php artisan sentry:test sends one exception. Within a few seconds the project's Errors page lists Exception: This is a test exception sent from the Sentry Laravel SDK.

2. What arrives, and what does not

stored

  • Uncaught exceptions and anything passed to captureException: type, message and the 50 frames nearest the crash. A Laravel request stack is longer than that; the frames above are cut, not the error.
  • captureMessage calls, as an issue of type Message.
  • Release, environment, the user id and email on the scope, tags, breadcrumbs and the request URL and method.
  • Levels fatal, error, warning and info; debug is stored as info.

accepted and dropped

Transactions, spans, profiles, sessions, cron check-ins, logs, metrics and attachments get a 200 and are discarded, so the SDK reports no failure. There is no tracing or cron product behind the DSN; keep Sentry for those if you use them.

Everything stored goes through the same pipeline as /v1/errors: the same per-error caps, error rate limit and monthly error budget, described on the migration page and in section 11 of api.md.

3. Release, environment and the user

SENTRY_RELEASE=2026.10.05        # config/sentry.php reads both; the Vinktar SDK below gets the same name
SENTRY_ENVIRONMENT=production
SENTRY_TRACES_SAMPLE_RATE=0      # sentry:publish writes 1.0, a transaction per request that is dropped here

The release and environment are the Sentry SDK's own options and arrive on every error. The user id is what joins an error to a person: without setUser an error from a signed-in request is anonymous. Use the same id you will pass to identify() below.

4. Then three product events

The DSN carries errors only. Product events come from vinktarhq/php, which is a beta: the API can still change before 0.2.0. It sends on the same write key, and the same release, environment and user id make the error and the person's events one record.

composer require vinktarhq/php:^0.2@beta

Event names and property keys are snake_case, the object then a past-tense action. Define each one as you add it, with define_event from your agent or in the project's data dictionary, so the name keeps one meaning. Under PHP-FPM what a request queues is sent when the request ends; a queue worker wraps each job in withScope() and calls flush() after it, as the SDK README shows.