It's time to prepare our app for production. So let's go ahead and add Sentry to our project. Using the link on the screen, you can get a special offer where you and your team can get Sentry for three months completely for free, as well as 150, 000 errors included. Now let's use Sentry's agentic setup. So instead of creating a new project, head into the resources where you can find documentation.
And up in the toolbar, go ahead and find AI. And select the agent plugin documentation. Now let's run their setup command inside of our project. Now go ahead and choose which coding agent you are using. By default, all three are selected, Cloud Code, Codex, and Cursor.
If you want to, you can leave it like this, so whoever in your team uses a different coding agent will have the same Sentry AI setup. Then go ahead and restart your coding agent or if you're using it within IDE like I am, go ahead and reload window. Then confirm that within your coding agent you now have a bunch of Sentry commands available. For the next step, I'd actually recommend going inside of the command line interface rather than using a graphical interface. Then go ahead and search for MCP servers.
Then scroll down until you find plugin Sentry and then select authenticate. The reason I'm telling you to do this through a command line interface rather than through a graphical interface is because I've had several unsuccessful attempts at authenticating an MCP server through the graphical interface But through the command line interface it worked on the first try. Make sure that you select all of these options and click approve and then approve once again. Once you've successfully authenticated the Sentry MCP, go ahead and run Sentry get started. Since we switched from a graphical interface to the command line interface, we have to manually approve tool use.
Or you can use shift tab to switch to auto mode here, so you can see it written in the lower left corner, which is the equivalent of what we had in the graphical interface, which is going to let Cloud Code automatically approve tool use. The Sentry agent will now find your team and it's going to look through your projects and it's probably going to ask you to create a new Sentry project. Since it read the browser automation directory name from my codebase, it will probably provide you with the name of your codebase as well. And that's what I'm going to choose, browser automation as my new Sentry project name. You should now have Sentry fully set up in your project and you should have a brand new project added in your Sentry dashboard.
My agent also developed a temporary API Sentry check endpoint and it attempted to throw an error within it. So now if I go inside of my issues, I can actually see that error being handled. So from now on, every single error we have in our application will immediately be monitored in the Sentry dashboard. The actual Sentry setup should consist of files like sentry edge config, sentry server config, the global error, a modification to the proxy so now it includes the monitoring, package.json which includes the sentry package, nextconfig which includes the with-sentry config with your Sentry information. And you should also have additional files like instrumentation.
For example, go ahead and use a free organization to run a workflow which uses premium nodes. As you know, that throws an error in our app, which is now actually visible in Sentry. So every single error that gets thrown will eventually surface in the Sentry. And you can see the exact stack trace, exactly what made that error happen, helping you debug and categorize whether this is a bug or expected error. This is a pretty good place to create a checkpoint with a commit.
Now you can run prompts like this. Add sentry logging to all relevant places in our codebase. But avoid adding it to the tasks folder as that is run in trigger.dev which is a separate environment. We can connect the two later. So essentially what I want now is the centry agent to go through our entire code base and to add relevant places to invoke SentryLogger.
SentryLogging is another feature of Sentry as useful as their errors and in fact they go hand in hand together because just seeing the error is useful but it would have been more useful if we had proper logs in place which then connect in this stack trace and the logs will tell you exactly which user tried something or which team tried something, whether the team was on the pro plan, on the free plan, whether they were trying to add an agent node or some other node. So that's what logs are extremely useful for. So instead of adding it to our codebase ourselves, let's just use the agent to do that. So add Sentry logging to all relevant places in our code base, but avoid adding it to the tasks simply because that is run inside of trigger.dev, which currently doesn't have access to Sentry. So I'm purposely leaving it out.
With such a simple prompt, we've now improved the logging and monitoring in our app, making it that much safer and ready for production. Let's take a look at the actions file. This is where all of our server actions are developed. A new Sentry import was added. Let's take a look at the create workflow action.
At the beginning of the action, Sentry is setting the attributes and defining which action this is, create workflow action, as well as adding the current organization ID to the scope. So every subsequent log which gets monitored will have that previous scope as well. Now let's scroll a bit down. Take a look at everything that's being logged. For example, if a user attempts to delete the workflow and it wasn't found, Sentry agent has added a log here.
Workflow delete skipped, not found. At first, this doesn't seem like such useful information. But if you start noticing the same ID and an invalid organization ID who doesn't belong in that workflow, all the time in your dashboard it might indicate that something is wrong with your UI and somehow it's deleting the workflow from another organization. That's why it's so useful to have these types of information because you will see anomalies. Scroll a bit down and you will find all kinds of interesting information added.
For example, whenever we throw an error that the agent node requires the pro plan, Sentry now warns us about that as well. So we can see exactly which errors appear more and which appear less. And if you scroll down, you will find even more useful information. And this is just in the actions file. Take a look at our API endpoints.
All of them now also have the attributes and another useful logging here. Session replay denied, pro plan required. So we are basically on top of every single thing that's happening. Every time that we successfully serve a session replay, We load the exact session ID for which organization on which page count of the browser-based session that was. Now take a look at the live blocks.
We did the same thing here. If we attempt to authenticate with live blocks with incorrect user IDs, we simply throw an error here as well but now we also warn it in Sentry. So every single thing that's happening in your app is now logged and you are aware of it. So if you now go ahead and just use your app, you don't even have to do anything special. And then go ahead and revisit your Explore logs.
In here, you will start to notice every single thing happening. So I ran a few workflows, triggered a few errors, and now I'm going to go back to the logs page. Take a look at this. You can actually see how your app breathes now. Every single thing that happened, every time a live blocks user was identified or resolved, Every time a workflow run was denied.
We keep track of everything. Now let's go ahead and stage and commit these changes as well. At this point, we are using Sentry to track some of the most important parts of our app, but we are still not tracking the actual background run. So let's go inside of features, tasks, run workflow. It would be great if somehow we managed to log every single thing that's happening inside of trigger.dev.
Now we have to be careful here because trigger.dev is a separate environment, not in our current Node.js or Next.js server. So how exactly do we connect the two in that case? Go ahead and search for Sentry and Trigger.dev and that will take you to Trigger example Sentry error tracking. And what you can do here is simply copy the entire page. Then go ahead and tell your agent to integrate Sentry with trigger and paste the entire documentation you just found.
So what should happen right now is a new dependency being added, SentryNode and another one called SentrySBuildPlugin. Then you should have a TriggerConfig modified which uses those new dependencies to modify the build property, add extensions, sbuild plugin and then use the Sentry sbuild plugin. You should recognize your organization and your project. The only thing we have to obtain is the Sentry Auth token. You should now also find init.ts inside of the features.
Now this isn't the best location for it. The reason it put the file here is because inside of trigger.dev, If you remember, let me find it, my apologies, trigger.config, we set the features directory to be the one where trigger is initialized. So technically, yes, this is correct place to put it, but perhaps it would have been better if it's inside of tasks. But for now, it's okay if it's here. And as you can see, we have registered trigger tasks so that every single time a failure happens, we log it to Sentry.
For example, an open URL node with an invalid URL is now getting logged to Sentry as well. So every single thing that happens in your trigger run will now be logged in Sentry. So you have one unified place for all of your errors and all of your monitoring. To obtain the SentryOut token, go inside of Settings, Organization, and scroll down until you find Organization Tokens, and go ahead and click Create New Token. Give this a name, Trigger.dev, and then create token.
Then go ahead and copy it and then go inside of your .environment.local and add a new field sentry out token and paste it here. The rest of the environment properties like sentry DSN and Node environment already exist in your project. So these are the ones mentioned inside of init.ds, which I just mentioned it's awkwardly put in the features folder. So the only one we actually have to take care of is inside of the trigger.config which is the SentryAlf token. So just make sure you didn't misspell it and that your agent actually uses this environment variable and added it here.
It might be a good idea to restart your development server and to restart your trigger.dev server. Now go ahead and purposely add an invalid URL to the open URL node. This is the easiest way to make this node fail. And let's go ahead and run. Now go inside of your trigger.dev dashboard and in your recent run you should see a failing task.
Cannot navigate to invalid URL. And because we have connected the two, the same error now appears in Sentry. So you officially have one place with all errors, monitoring, logging and observability. Now let's go ahead and stage and commit our changes. It's been a while since we updated our railway deployment with our newest environment variable keys.
So let's make sure that we copy the latest ones and add them to our railway service. Those will be recent API key, next public sentry DSN, sentry DSN and sentry auth token. So go inside of variables, raw editor and the last one as you can see is browser-based API key. So let's simply add Resend, NextPublicSentry, Sentry and SentryAuthToken and then deploy. And if you haven't already, make sure that you push your newest changes.