Set Up Sentry Projects for Kernelkain

I’m using the Sentry setup workflow to detect the app’s stack, provision the right project(s) in kernelkain, install the SDK, and verify telemetry. I’ll also consult the repository’s Entire guidance before changing code, plus a brief community check for current integration pitfalls.

Sentry is an application monitoring platform: it captures errors and crashes and ties them to the release, request, and source line that caused them. It can also add tracing, logs, profiling, replay, cron and uptime monitoring. I’m taking a quick look at both the account and repository now, then I’ll carry the setup through to a confirmed test event.

I found a full-stack TypeScript application: a Node.js/Hono server serving a React/Vite client, with no Sentry SDK installed and no existing Sentry projects in the organization. The clean setup is two projects—one Node project for server errors/traces and one React project for browser errors—so each runtime has the correct SDK, DSN, and source-map path. I’m checking the current official setup details before provisioning them.

The current Sentry catalog includes a dedicated Hono integration, which is a better fit than treating the backend as generic Node. I’m validating that integration and the Vite browser setup together so distributed traces can connect cleanly across the client/server boundary.

I found a Hono/Node backend and React/Vite frontend. Shall I create these two Sentry projects under team kernelkain?

• unfinished-business-server — Hono/Node
• unfinished-business-web — React

I’ll then install both SDKs, configure tracing and source maps, and verify real test errors end to end.

Confirmed. I’ll provision the two projects now, then wire the backend and frontend SDKs into the real application startup paths. After that I’ll run the app and confirm identifiable test errors in both Sentry projects.

Both projects now exist:

• unfinished-business-server — DSN https://e0fb5afecfe3b6683c87b189fe431e92@o4512343451435008.ingest.de.sentry.io/4512349803577424
• unfinished-business-web — DSN https://62d2843b479e9ef671941ae38d95e893@o4512343451435008.ingest.de.sentry.io/4512349804167248

I’m moving into application instrumentation. The DSNs are client configuration values; the source-map upload token, if added later, will remain a private CI secret.

The app’s workshop data can contain private product ideas and session tokens, so I’m configuring error/tracing telemetry without sending request bodies, cookies, query strings, or user identity. Tracing will sample 100% in development for verification and 10% in production; the browser and server will share trace headers on same-origin API calls.

Package installation is still waiting on the registry with no output, so I’m checking whether it’s a sandboxed network stall. If it fails for that reason, I’ll request the narrow network permission needed for npm and continue without changing the design.

The integration compiles cleanly: typecheck, production build, and all eight test files pass. The only build warning is the existing large client bundle; I’m checking the dependency audit separately, then I’ll boot the real app and send one server and one browser verification error.

The real server is running on loopback and the gated endpoint returned the expected HTTP 500, so the backend signal has been emitted through Hono’s actual middleware. I’m now opening the built frontend with its one-time query trigger to emit the browser signal through the real React entry point.

Both events landed:

• Server: Error: Sentry verification server 20261031-001 — UNFINISHED-BUSINESS-SERVER-1
• Browser: Error: Sentry verification web 20261031-002 — UNFINISHED-BUSINESS-WEB-1

I’m inspecting both stack traces now, then I’ll remove the temporary verification triggers and rerun the test/build checks.

The server stack trace is readable down to src/server/app.ts, including source context. The browser event is correctly captured and has a masked session replay, but its stack is minified because source-map upload needs a private SENTRY_AUTH_TOKEN; the Vite upload configuration is already in place and activates when that CI secret is present. I’m removing both test-only triggers now.

Cleanup is complete and the final typecheck, production build, and all tests pass again. One dependency caveat remains: Sentry 11.10.0 currently pulls glob/minimatch versions flagged by npm as moderate; npm’s suggested automatic fix is a breaking Sentry downgrade, so I’m leaving the supported current SDK intact and recording that risk rather than forcing it.

Local setup is complete and verified for both Sentry projects. The remaining production step depends on your hosting/CI platform so I can configure releases, environment variables, and source-map uploads correctly.

How do you deploy this application—Vercel, Render, Fly.io, Docker/GitHub Actions, or something else?

Sentry is fully configured and verified locally for both application runtimes.

• Created unfinished-business-server for Hono/Node.
• Created unfinished-business-web for React/Vite.
• Installed Sentry error monitoring, tracing, Node profiling, browser replay, and user feedback.
• Added privacy controls that exclude request bodies, headers, cookies, query parameters, user identity, AI content, and stack variables.
• Configured 100% development tracing and 10% production tracing.
• Added React 19 error handlers and Hono middleware.
• Prepared Vite source-map uploads, activated when SENTRY_AUTH_TOKEN is available.
• Added DSN and environment examples to .env.example.
• Updated startup and build configuration in package.json and vite.config.ts.

Key implementation files:

• server instrumentation
• server startup
• Hono middleware
• browser instrumentation
• React error handling

End-to-end verification succeeded:

• Server verification issue — readable TypeScript stack and source context.
• Browser verification issue — captured with a masked session replay.
• Temporary verification routes and triggers were removed afterward.
• Typecheck, production build, and all eight test files pass.

Remaining production work:

• Add SENTRY_AUTH_TOKEN to CI so browser source maps upload.
• Set production environment and release values.
• Wire those settings into the deployment platform once it is identified.
• Optionally resolve the two test issues in Sentry.
• npm reports six moderate advisories in Sentry’s transitive glob/minimatch dependencies; its proposed fix is a breaking SDK downgrade, so it was not applied.