Connecting Deploynix to Sentry for Error Tracking in Production

Deploynix gives you server-level monitoring — CPU, memory, disk, and health alerts. But server metrics tell you whether your infrastructure is healthy. They do not tell you whether your application is working correctly.

A server running at 10% CPU with plenty of memory can still be throwing 500 errors on every third request. A queue worker can be processing jobs "successfully" while silently swallowing exceptions. A scheduled task can fail halfway through and leave data in an inconsistent state.

This is where Sentry comes in. Sentry captures application-level errors, exceptions, and performance issues with the context you need to debug them: stack traces, request data, user information, breadcrumbs, and more.

Deploynix and Sentry together give you full-stack observability: infrastructure health from Deploynix and application health from Sentry. This guide covers how to connect them properly, going beyond the basic SDK installation to include release tracking, source maps, environment tagging, and automated deploy notifications.

Installing the Sentry Laravel SDK

Start by installing the Sentry SDK for Laravel:

composer require sentry/sentry-laravel

Publish the Sentry configuration file:

php artisan sentry:publish --dsn=YOUR_SENTRY_DSN

This creates config/sentry.php and adds the SENTRY_LARAVEL_DSN entry to your .env file.

If you prefer to configure manually, add these environment variables to your site's environment in the Deploynix dashboard:

SENTRY_LARAVEL_DSN=https://examplePublicKey@o0.ingest.sentry.io/0
SENTRY_TRACES_SAMPLE_RATE=0.1

The DSN (Data Source Name) is found in your Sentry project settings under Client Keys (DSN). The traces sample rate controls what percentage of requests generate performance traces — 0.1 means 10% of requests, which is a good starting point for production.

Verifying the Installation

After deploying with the Sentry configuration in place, you can verify the connection by triggering a test exception. Add a temporary test route:

Route::get('/debug-sentry', function () {
    throw new \Exception('Sentry test exception from Deploynix');
});

Visit the route, then check your Sentry dashboard. You should see the exception appear within a few seconds. Remove the test route after verification.

Environment Tagging

Laravel applications typically run in multiple environments: local development, staging, and production. Sentry should distinguish between these environments so you can focus on production errors without noise from development.

In your Deploynix environment variables, set:

SENTRY_ENVIRONMENT=production

For staging servers, set:

SENTRY_ENVIRONMENT=staging

Sentry uses this value to tag every event, allowing you to filter by environment in the dashboard. You can also configure alert rules that only trigger for production errors, so staging issues do not wake anyone up.

In config/sentry.php, the environment is typically pulled from the SENTRY_ENVIRONMENT variable or falls back to APP_ENV:

'environment' => env('SENTRY_ENVIRONMENT', env('APP_ENV', 'production')),

This is important because APP_ENV might be set to production on both your production and staging servers. Using a separate SENTRY_ENVIRONMENT variable gives you explicit control.

Release Tracking

Release tracking is one of Sentry's most powerful features for production debugging. When you associate errors with specific releases, you can:

• See which release introduced a new error.
• Track error rates per release to determine if a deployment made things better or worse.
• Identify regressions immediately after deployment.
• Correlate error spikes with specific code changes.

Configuring Releases

The simplest approach is to use your Git commit SHA as the release identifier. In your Deploynix deploy script, you can capture the current commit and pass it to Sentry:

Add this to your site's environment variables on Deploynix:

SENTRY_RELEASE=

Then, in your deploy script (after the code is pulled), set the release dynamically:

# In your deploy script
COMMIT_SHA=$(git rev-parse HEAD)
sed -i "s/SENTRY_RELEASE=.*/SENTRY_RELEASE=${COMMIT_SHA}/" .env

Alternatively, you can use a more readable release format that includes a version number or date:

RELEASE="deploynix-$(date +%Y%m%d)-$(git rev-parse --short HEAD)"
sed -i "s/SENTRY_RELEASE=.*/SENTRY_RELEASE=${RELEASE}/" .env

In config/sentry.php, read the release from the environment:

'release' => env('SENTRY_RELEASE'),

Why Release Tracking Matters

Without release tracking, Sentry shows you a flat timeline of errors. You see that an error started occurring on Tuesday, but you do not know which of the three deployments on Tuesday introduced it.

With release tracking, Sentry shows you exactly which release first triggered the error. You can click through to the commit, see the diff, and identify the cause in minutes instead of hours.

Source Maps for Frontend Errors

If your Laravel application has a JavaScript frontend — whether it is Alpine.js with inline scripts, a Livewire application with JavaScript interactions, or a full single-page application — Sentry can capture frontend errors too. But minified JavaScript stack traces are useless without source maps.

Installing the Sentry Browser SDK

If you are using Vite (which is the default for Laravel), install the Sentry browser SDK:

npm install @sentry/browser

Initialize Sentry in your main JavaScript file:

import * as Sentry from "@sentry/browser";

Sentry.init({
    dsn: "YOUR_SENTRY_DSN",
    environment: document.querySelector('meta[name="sentry-environment"]')?.content || "production",
    release: document.querySelector('meta[name="sentry-release"]')?.content,
    integrations: [
        Sentry.browserTracingIntegration(),
    ],
    tracesSampleRate: 0.1,
});

Add the meta tags in your Blade layout:

Uploading Source Maps

Source maps let Sentry unminify your JavaScript stack traces, showing you the original file, line number, and function name instead of app-DfG8h2k.js:1:34982.

Install the Sentry Vite plugin:

npm install @sentry/vite-plugin

Configure it in vite.config.js:

import { sentryVitePlugin } from "@sentry/vite-plugin";

export default defineConfig({
    build: {
        sourcemap: true,
    },
    plugins: [
        laravel({
            input: ['resources/css/app.css', 'resources/js/app.js'],
            refresh: true,
        }),
        sentryVitePlugin({
            org: "your-sentry-org",
            project: "your-sentry-project",
            authToken: process.env.SENTRY_AUTH_TOKEN,
        }),
    ],
});

The SENTRY_AUTH_TOKEN is a Sentry authentication token that allows the Vite plugin to upload source maps during the build process. Generate one in your Sentry account under Settings > Auth Tokens.

Add the token to your Deploynix environment:

SENTRY_AUTH_TOKEN=your_auth_token_here

Now, when your deploy script runs npm run build, the Sentry Vite plugin automatically uploads source maps to Sentry and associates them with the current release. Frontend errors will show deobfuscated stack traces with your original source code.

Security note: Source maps are uploaded to Sentry's servers but are not served to your users. Your users still receive the minified JavaScript. The source maps are only used by Sentry to deobfuscate error reports.

Deploy Notifications from Your Deploy Script

Sentry's deploy tracking goes beyond releases. When you tell Sentry about a deployment, it:

• Marks the release as deployed to a specific environment.
• Resolves issues that were marked as "resolved in next release."
• Sends notifications to team members about the deployment.
• Starts tracking the new release's error rate for regression detection.

You can notify Sentry of deployments directly from your Deploynix deploy script. Add this to your deploy script:

SENTRY_RELEASE=$(git rev-parse HEAD)
SENTRY_ENVIRONMENT="production"
SENTRY_ORG="your-sentry-org"
SENTRY_PROJECT="your-sentry-project"
SENTRY_AUTH_TOKEN="your-auth-token"

curl -s https://sentry.io/api/0/organizations/${SENTRY_ORG}/releases/ \
  -H "Authorization: Bearer ${SENTRY_AUTH_TOKEN}" \
  -H "Content-Type: application/json" \
  -d "{
    \"version\": \"${SENTRY_RELEASE}\",
    \"projects\": [\"${SENTRY_PROJECT}\"]
  }"

curl -s https://sentry.io/api/0/organizations/${SENTRY_ORG}/releases/${SENTRY_RELEASE}/deploys/ \
  -H "Authorization: Bearer ${SENTRY_AUTH_TOKEN}" \
  -H "Content-Type: application/json" \
  -d "{
    \"environment\": \"${SENTRY_ENVIRONMENT}\",
    \"name\": \"Deploynix deployment $(date +%Y-%m-%d_%H:%M:%S)\"
  }"

The first curl command creates the release in Sentry (if it does not already exist). The second command records the deployment. Together, they give you a complete deployment history in Sentry's release dashboard.

For a cleaner deploy script, you can extract the Sentry notification into a shell script and reference environment variables stored in the Deploynix dashboard:

# deploy script
bash scripts/notify-sentry.sh

Configuring Alerts

With Sentry receiving your errors and deployment information, configure alerts to notify your team when things go wrong.

Recommended Alert Rules

New issue alert: Triggers when Sentry sees an error it has never seen before. This catches bugs introduced by new deployments immediately.

• Conditions: A new issue is created.
• Actions: Send notification to your team's Slack channel or email.
• Frequency: At most once every 30 minutes per issue.

High-frequency alert: Triggers when an existing error suddenly starts occurring much more frequently, indicating a potential regression or infrastructure issue.

• Conditions: The number of events in an issue exceeds 100 in 1 hour.
• Actions: Send notification with "critical" severity.
• Frequency: At most once per hour.

Environment-specific alerts: Configure production alerts to page your on-call team while staging alerts send to a low-priority Slack channel. This prevents staging noise from causing alert fatigue.

Performance Alerts

If you have performance tracing enabled (via SENTRY_TRACES_SAMPLE_RATE), configure performance alerts for:

• Slow transactions: Alert when the p95 response time for a specific route exceeds your SLA threshold.
• Throughput changes: Alert when the number of transactions drops significantly, which might indicate that users cannot reach your application.

Best Practices for Production

Sample Rates

In production, capturing 100% of transactions for performance monitoring is expensive and unnecessary. A sample rate of 0.1 (10%) provides statistically significant performance data without overwhelming your Sentry quota.

For error events, Sentry captures all errors by default (there is no sampling). This is correct — you want to know about every error, not a statistical sample of errors.

Sensitive Data Scrubbing

Laravel applications often handle sensitive data: passwords, API keys, credit card numbers, personal information. Sentry automatically scrubs some sensitive fields, but you should configure additional scrubbing.

In config/sentry.php:

'before_send' => function (\Sentry\Event $event): ?\Sentry\Event {
    // Remove sensitive request data
    $request = $event->getRequest();
    if ($request) {
        $data = $request->getData();
        $sensitiveFields = ['password', 'password_confirmation', 'credit_card', 'ssn', 'token'];
        foreach ($sensitiveFields as $field) {
            if (isset($data[$field])) {
                $data[$field] = '[Filtered]';
            }
        }
        $request->setData($data);
    }
    return $event;
},

Also configure Sentry's server-side data scrubbing in your project settings under Security & Privacy. Enable "Enhanced Data Scrubbing" and add any application-specific sensitive field names.

Ignoring Known Errors

Some errors are expected and do not require attention: 404s from web crawlers, validation exceptions from user input, authentication failures from brute force attempts. Configure Sentry to ignore these:

'ignore_exceptions' => [
    \Symfony\Component\HttpKernel\Exception\NotFoundHttpException::class,
    \Illuminate\Validation\ValidationException::class,
    \Illuminate\Auth\AuthenticationException::class,
],

This keeps your Sentry dashboard focused on actual bugs rather than expected application behavior.

Queue and Job Monitoring

Sentry captures exceptions from queue workers automatically through the Laravel integration. But you can add additional context to job errors:

use Sentry\Laravel\Integration;

class ProcessPayment implements ShouldQueue
{
    public function handle(): void
    {
        Integration::addBreadcrumb(new \Sentry\Breadcrumb(
            \Sentry\Breadcrumb::LEVEL_INFO,
            \Sentry\Breadcrumb::TYPE_DEFAULT,
            'queue',
            'Processing payment',
            ['order_id' => $this->order->id, 'amount' => $this->order->total]
        ));

        // Process payment...
    }
}

Breadcrumbs create a trail of events leading up to an error, giving you context about what happened before the exception was thrown.

Putting It All Together

With Sentry properly configured alongside Deploynix, your observability stack covers both layers:

Deploynix monitors your infrastructure: CPU load, memory usage, disk space, server health. Alerts fire when hardware resources are constrained.

Sentry monitors your application: Exceptions, slow transactions, failed jobs, frontend errors. Alerts fire when your code is not behaving correctly.

Release tracking connects deployments to errors: You know which deployment introduced a bug, which commit caused it, and whether the fix you deployed actually resolved it.

This is production-grade monitoring without the complexity of building your own observability pipeline. Deploynix handles the infrastructure. Sentry handles the application. You handle the code.