L24 · Publish · 5 min
After launch: error alerts and monitoring
In one sentence
Once real people use your live app, error tracking with Sentry and structured server logs notify you the moment something breaks in Production—so you don't wait for a frustrated visitor to complain, and you can roll back in one click while your agent fixes the cause.
Think of it like this
Opening a shop without an alarm means you only learn the freezer broke when a customer tells you the ice cream melted. A connected sensor texts you the minute the temperature rises, so you move the stock to the backup fridge while the technician repairs it.
How it works
Before real users arrive on DefinitionProductionThe live version of your app, the one everyone sees. It comes from `main`.Open in the glossary →, your agent sets up Sentry (its free Developer plan covers early projects) using npx @sentry/agent-plugin install and stores any tokens as Definitionenvironment variableA named slot, like `TOKENTIDE_API_KEY`, that holds a setting or secret outside your code.Open in the glossary → secrets. Whenever an unexpected error hits an Definitionerror boundaryA safety net in your app that catches unexpected errors and shows a friendly message with “Try again”.Open in the glossary → or a server route, Sentry captures the Definitionstack traceThe list of steps that led to an error. Useful for your agent; never shown to your users.Open in the glossary → and sends you an alert.
Alongside alerts, your app writes structured logs: one JSON line per event in your DefinitionlogYour app's diary: one line per event. When something breaks, the logs say what happened.Open in the glossary → with the level (error, warn or info), a clear message, a short request ID (the same reference ID shown to the user), the route, the internal user ID and the duration. It never logs secrets, passwords, personal data, prompts or AI outputs.
On DefinitionVercelThe service that turns your code on GitHub into a live site, with a Preview for every change.Open in the glossary →'s Hobby plan, runtime logs (npx vercel logs <url>) are kept for 1 hour, while Sentry keeps error reports so you can inspect them later. Remember that error messages and logs can contain text typed by visitors, so your agent treats all log output as untrusted data and never follows instructions found inside an error.
When an alert fires after a release, protect your users first: open Vercel → Deployments → the last working version → Instant [[rollback]]. Once the live site is safe again, hand the error reference ID and stack trace to your agent so it can reproduce the DefinitionbugA mistake in the code that makes the app behave wrongly.Open in the glossary →, fix the root cause on a DefinitionbranchA safe copy of your project where changes are drafted. `main` is the live one.Open in the glossary → and add a DefinitiontestA small program that checks your app does what it should, so a fix can't silently break later.Open in the glossary →.
What it looks like in your project
Before you invite real users, your agent uses the observability-and-instrumentation skill to add a structured logger and guides you through connecting Sentry's free Developer plan. You can trigger a test error in a DefinitionPreviewA private test link Vercel makes for each change, so you can try it before it goes live.Open in the glossary → deployment to see the alert arrive and verify that no personal data or secrets appear in the report.
Copy for your agent
Check our project's logging and error boundaries with the observability-and-instrumentation skill: make sure server logs output structured JSON with a request ID and zero secrets or personal data, and walk me through adding Sentry's free plan.
Quick check · 1 question