Error Tracking for Bun Apps

Bun is reshaping the JavaScript ecosystem. Written in Zig and built for speed, this all-in-one runtime for JavaScript and TypeScript handles package management, testing, and bundling alongside code execution. But speed alone doesn't ship production software—reliability does. As more teams adopt Bun.sh server error tracking becomes essential to maintain the confidence that metrics like 2.7x faster startup times deserve.

Error tracking for Bun differs meaningfully from traditional Node.js monitoring. Bun's async-first architecture, lack of CommonJS baggage, and aggressive optimization mean stack traces, async context propagation, and performance timings demand tooling built to understand this runtime's unique characteristics. LightTrace, Sentry-compatible and vendor-neutral, captures these traces faithfully and delivers them to a dashboard built for debugging—no noise, no guesswork.

What Makes Bun Different for Error Tracking

Bun is not Node.js with a different engine. Its performance comes from architectural choices that ripple through error handling and observability.

Async-first execution: Bun treats async operations as native primitives, not bolted-on callbacks. This means stack traces carry richer context about which promise settled before an error occurred. Most error trackers lose this context; LightTrace preserves it.

Top-level await: Bun scripts execute top-level awaits directly, without an IIFE wrapper. Error handlers that attach to process don't exist; instead, you'll use Bun-specific globals like Bun.serve().

Built-in tooling: Bun ships with a test runner and bundler. Errors in your tests or build pipeline integrate with the same monitoring setup. A single error tracker covers your entire workflow.

WebSocket and streaming natives: Bun's HTTP server and WebSocket API are faster and more memory-efficient. Real-time features that would stutter in Node.js run smoothly, but transient errors from dropped connections matter more when your app is under higher throughput.

Setting Up LightTrace with Bun

Start by installing the Sentry SDK for Node.js. Bun maintains compatibility with npm packages, so the same setup works:

bun add @sentry/node

Initialize the SDK in your entry point. Here's a real Bun HTTP server:

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

Sentry.init({
  dsn: "https://<your-key>@light-trace.robomiri.com/1",
  tracesSampleRate: 1.0,
  environment: Bun.env.NODE_ENV || "development",
});

export default {
  fetch(request: Request) {
    try {
      return new Response("OK", { status: 200 });
    } catch (error) {
      Sentry.captureException(error);
      return new Response("Internal Server Error", { status: 500 });
    }
  },
  port: 3000,
};

The dsn is your LightTrace endpoint. Set it to https://<your-key>@light-trace.robomiri.com/1, replacing the host and key with your LightTrace credentials.

Capturing Async Errors

Bun's async model is powerful but unforgiving. An unhandled promise rejection can crash your server if not caught. Wrap async handlers and use Sentry's middleware pattern:

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

export default {
  fetch(request: Request) {
    const transaction = Sentry.startTransaction({
      op: "http.server",
      name: request.url,
    });

    return Sentry.withScope(() => {
      Sentry.setContext("http", {
        method: request.method,
        url: request.url,
      });

      (async () => {
        try {
          const response = await handleRequest(request);
          transaction.finish();
          return response;
        } catch (error) {
          Sentry.captureException(error);
          transaction.setStatus("internal_error");
          transaction.finish();
          return new Response("Error", { status: 500 });
        }
      })();
    });
  },
  port: 3000,
};

async function handleRequest(request: Request) {
  // Your logic here
  return new Response("OK");
}

LightTrace will receive the full async stack trace, including breadcrumbs of prior operations, so you can reconstruct what led to the failure. Unlike raw error logs, this context is parsed and indexed for searching.

Distributed Tracing Across Bun Services

As you scale, a single error often involves multiple services. Bun is lightweight enough that microservice architectures make sense. LightTrace supports distributed tracing across multiple projects, letting you follow a request from your API through a background worker to a database query.

Attach trace headers to outbound requests:

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

async function callDownstream(url: string) {
  const transaction = Sentry.getCurrentHub().getActiveTransaction();
  const span = transaction?.startChild({
    op: "http.client",
    description: `GET ${url}`,
  });

  const headers: Record<string, string> = {
    ...Sentry.getTracePropagationHeaders(),
  };

  const response = await fetch(url, { headers });
  span?.finish();
  return response;
}

Your downstream Bun services must initialize Sentry with the same DSN. LightTrace will automatically stitch traces together, building a waterfall view of where time is spent and where errors originate.

Breadcrumbs: Tracking What Happened Before the Error

Breadcrumbs are lightweight event logs—HTTP requests, database queries, cache hits—that Sentry captures automatically and LightTrace stores alongside each error. In Bun, this is invaluable because async operations can be separated in time from the eventual crash.

Manually add breadcrumbs when they matter:

Sentry.addBreadcrumb({
  category: "database",
  message: "User query started",
  level: "info",
  data: { query: "SELECT * FROM users WHERE id = ?" },
});

const user = await db.query("SELECT * FROM users WHERE id = ?", [userId]);

Sentry.addBreadcrumb({
  category: "database",
  message: "User query completed",
  level: "info",
  data: { rowCount: user.length },
});

When an error occurs later in the request, you'll see this sequence in LightTrace, turning a cryptic stack trace into a story you can debug.

Best Practices for Bun Error Tracking

Set the environment: Tag errors by deployment stage (development, staging, production) so you can filter alerts and avoid false alarms during testing.

Sentry.init({
  environment: Bun.env.NODE_ENV || "development",
  // ...
});

Use source maps: Bun's bundler can generate source maps. Tell Sentry where to find them so stack frames point to your original TypeScript, not compiled output:

Sentry.init({
  dsn: "https://<key>@light-trace.robomiri.com/1",
  integrations: [new Sentry.Integrations.SourceMaps()],
  // ...
});

Profile releases: When you deploy, tell LightTrace the version. You can then filter errors by release, spot regressions instantly, and track crash-free health over time:

Sentry.init({
  release: Bun.env.APP_VERSION,
  // ...
});

Alert on new issues: LightTrace sends email alerts when a new error fingerprint appears. This catches unexpected problems before users do. Learn more about setting up error tracking to cover your full stack.

Comparing Approaches

If you're comparing Bun error tracking solutions, LightTrace is a faster, more affordable hosted alternative to on-premises or complex setups. You get:

• Sentry SDK compatibility: No SDK rewrites, just point your existing code at a new endpoint.
• Mobile-first dashboard: Browse errors on your phone during outages.
• GitHub integration: Stack frames link directly to the code on GitHub.
• Native symbolication and source maps: Denormalize minified Bun bundles automatically.
• Email alerts: New issues and frequency thresholds—no PagerDuty markup.

Bun is still young, and so is its ecosystem. By adopting error tracking now, you're building the observability practices that will carry your app through growth. Your future self—debugging a production incident at 2am—will thank you.