Sentry Error Tracking — How Velocity X Catches Production Bugs Before Customers Do

Here's the reality: code runs fine in your local environment and passes staging. Then you ship to production. A customer clicks a button. An unexpected API response crashes your Edge Function. A third-party script throws an uncaught error in the browser. Your user gets a blank screen. You find out six hours later when they email support. Sentry flips that timeline. Every exception in production is logged, grouped, and routed to Slack within seconds. You don't wait for complaints. You see the error, read the full stack trace, understand the context, and fix it before the customer even finishes typing their support email. Combined with source maps and release tagging, Sentry transforms error tracking from "we'll debug it when someone complains" into "we caught it at impact time." Velocity X uses Sentry for both frontend (browser exceptions) and backend (Edge Function crashes). Here's how the setup works and why it matters.

Why Error Tracking Matters in Production

Staging and local environments never fully replicate production. Real-world traffic patterns, edge-case data, user networks, and third-party integrations all introduce variables your staging can't simulate. An error that never appears in controlled testing will eventually surface in production—and you'll feel it in churn, support load, and reputation.

Error tracking doesn't prevent bugs. It ensures you know about them the instant they happen. The faster you know, the faster you can fix. That window shrinks from "when will a customer complain?" to "right now, see the stack trace."

Sentry Setup: Frontend SDK

Install the browser SDK:

{`npm install @sentry/astro @sentry/tracing
`}

Initialize it in your Layout or app entry point:

{`import * as Sentry from "@sentry/astro";

Sentry.init({
  dsn: import.meta.env.SENTRY_DSN,
  environment: import.meta.env.PUBLIC_ENV,
  integrations: [
    new Sentry.Replay({
      maskAllText: true,
      blockAllMedia: true,
    }),
  ],
  tracesSampleRate: 0.1,
  replaysSessionSampleRate: 0.1,
  replaysOnErrorSampleRate: 1.0,
});
`}

That's the bare minimum. Every unhandled exception in the browser is now captured. Environment tagging (dev/staging/prod) keeps errors organised by deployment stage. Session replay captures the last 5 seconds before the error—mouse movements, clicks, network requests—so you can reproduce the user's exact path to the bug.

Sentry Setup: Backend SDK (Edge Functions)

Your Edge Functions run on Netlify's servers. Crashes there don't show in browser logs. Install the Node SDK:

{`npm install @sentry/node
`}

Initialise in your Edge Function handler:

{`import * as Sentry from "@sentry/node";

Sentry.init({
  dsn: Deno.env.get("SENTRY_DSN"),
  environment: Deno.env.get("ENV"),
  tracesSampleRate: 1.0,
});

export default async (request: Request) => {
  try {
    // your function logic
    return new Response(JSON.stringify({ success: true }));
  } catch (error) {
    Sentry.captureException(error);
    return new Response(
      JSON.stringify({ error: "Internal error" }),
      { status: 500 }
    );
  }
};
`}

Now backend errors are captured with full context: request payload, environment variables (non-sensitive), function duration, memory usage. Combined with frontend tracking, you have visibility across your entire stack.

Source Maps: Readable Stack Traces

Minified code is unreadable. A stack trace like `at l (bundle.abc123.js:1:9999)` tells you nothing. Source maps translate that back to your original code: `at handleClick (components/Button.tsx:45:12)`. Without source maps, production debugging is guesswork.

Upload source maps at build time:

{`npm run build

npx @sentry/cli releases files upload-sourcemaps ./dist \\
  --org=your-org \\
  --project=your-project \\
  --release=$(git rev-parse HEAD)
`}

Wire it into your CI/CD pipeline (GitHub Actions, Netlify Build):

{`- name: Upload source maps to Sentry
  run: |
    npm run build
    npx @sentry/cli releases files upload-sourcemaps ./dist \\
      --org=your-org \\
      --project=your-project \\
      --release=${{ github.sha }}
  env:
    SENTRY_AUTH_TOKEN: \${{ secrets.SENTRY_AUTH_TOKEN }}
`}

Every release gets tagged with its git SHA. Errors are automatically linked to the commit that shipped them. You'll see stack traces in your original TypeScript/JSX, not minified garbage.

Release Tagging via Git SHA

Sentry doesn't know which commit is in production. You have to tell it. Use git SHA as the release identifier:

{`Sentry.init({
  dsn: process.env.SENTRY_DSN,
  release: process.env.COMMIT_SHA, // e.g., "4f09dc8"
  environment: process.env.ENV,
});
`}

Now when an error occurs, Sentry shows you the exact commit that introduced it. Click through to GitHub, see the code diff. Understand not just *that* something broke, but *why*. You can revert that commit with confidence because you know it's the culprit.

Alert Routing: Critical to Slack, Low-Priority to Digest

Not all errors are equal. A 500 from an internal API call affects production. A failed analytics beacon doesn't. Alert overload kills signal. Sentry's alert rules let you route by severity:

• Critical (status 5xx, user-facing): Slack immediately, high priority channel, ping @on-call
• Warning (status 4xx, non-critical): Slack summary, daily digest
• Info (analytics, third-party): Sentry dashboard only, no alert

In Sentry's Issues section, create rules like:

{`Rule: "Status code equals 5xx AND exception in payment flow"
Action: Send to #sentry-critical (Slack)

Rule: "Error message contains 'analytics' OR 'tracking'"
Action: Send to #sentry-digest (daily email summary)

Rule: "Environment equals staging"
Action: Sentry dashboard only (no alert)
`}

Your team sees critical errors in seconds. Low-priority noise doesn't clutter Slack. You stay responsive without being spammed.

Six FAQs

How much does Sentry cost?

Free tier covers 5k events/month. Most small-to-mid businesses fit comfortably. Velocity X uses the Pro plan (~$25/month) for higher event limits and advanced features like replays and release tracking. No sweat for the visibility you get.

Does Sentry slow down my site?

Negligible impact. The SDK is lazy-loaded and non-blocking. Error reporting happens in the background. Session replays are sampled (1% of sessions by default, 100% on error). No user-facing slowdown.

What data is Sentry seeing?

By default: stack trace, environment, browser/OS, request URL. You control what else: set `beforeSend` hooks to scrub sensitive data (passwords, tokens, PII). Session replays are configurable—mask text, block media, exclude specific elements. You stay compliant with privacy laws.

Can I integrate Sentry with other tools?

Yes. Sentry integrates with Slack, PagerDuty, GitHub (links errors to repos), Jira (creates tickets), Discord, Datadog. You can route alerts to your existing incident-response workflow.

What if an error is spam?

Mark it as "Ignored" or "Resolved" in the Sentry dashboard. Future events from that error won't trigger alerts. You can also set up rules to auto-ignore known, non-critical errors (e.g., third-party ad scripts throwing).

How do I test that Sentry is working?

Throw an intentional error in your app. Reload. Check the Sentry dashboard 5–10 seconds later. The error should appear with full context. Once you see it, delete the test code and you're done.

The Bottom Line

Error tracking isn't optional in production. Code breaks. Networks fail. Third-party scripts misbehave. The question isn't "will errors happen?" but "how fast will you know?" Sentry collapses that window from hours to seconds. Combined with source maps, release tagging, and smart alert routing, you go from reactive debugging (waiting for complaints) to proactive fixing (seeing errors in real time). Like performance budgets catch regressions at commit time, error tracking catches bugs at impact time.

Ready to stop waiting for error reports? Check Velocity X pricing to see how production monitoring fits into a resilient build pipeline.