For the majority of my life now, I have been building different software products. For observability, I’ve always just stuck with the usual setup of using logging on the backend, with Sentry on the front-end.

During the years I have been shipping products, the full-stack dev experience has come a long way from the days of deploying using FTP clients (s/o FileZilla) to manually move the assets etc. Nowadays we have 10 second push to deploy (or push to deploy is the norm), we have full-stack frameworks that make code-reuse, routing, caching, optimizations and shipping so much faster in general. I could go on forever.

However, It feels like the full-stack error monitoring and bug-fixing experience has been lacking the same massive gains in developer experience that were made in all other parts of the dev lifecycle.

The front-end error monitoring experience

On the front-end of things, I used to use Sentry to find possible front-end bugs. The problem I quickly found out with Sentry and similar tools are that they just catch all exceptions, including useless exceptions from browser extensions, a user’s internet connection dropping or something similar.

What ended up happening was that the large amount of unrelevant error alerts subdued me with time, and I stopped paying attention to the error alerts, and just went back to listening to error reports from user feedback.

And even when bugs are reported, they contain a often unhelpful stacktrace, leaving you more or less stranded when trying to reproduce what exactly happened.

The front-end error monitoring is like some kind of reverse Pareto principle, where 80% of the errors are useless, and drown out the 20% that are actual bugs. A very low signal to noise ratio.

Back-end error monitoring experience

On the back-end of things, I always used traditional log lines dispersed throughout the code, hoping that the context from the logs would be enough to fix any possible bugs that might happen on the back-end.

Low signal over noise

In practice however, this suffers from some problems. Firstly, the volume of logs makes it difficult to find the relevant context for quickly fixing problems, and a lack of structure can make it overwhelming to find relevant information. Stripe has written a great blog post about how they structure their logs and codified them to combat these problems at scale with canonical log lines.

Even then, my workflows for troubleshooting bugs and finding useful information is still almost as archaic as it was 10+ years ago. I get a tail of a bunch of log lines, filter down by a user’s email, the date of the error, finding the ones that I think might be useful, and then try to connect the dots for useful information.

Once again here we have massive noise over signal. There must be a better way. One that shows only the relevant data and only the relevant context.

We have full-stack frameworks that are great for building whole applications, front ends and APIs, but we lack a full-stack error monitoring / debugging solution that combines data from both front- and backend to make one cohesive monitoring & debugging experience.

The tool I always wanted

The error monitoring and bug fixing tool ties all of this together, showing only actual errors in your code, combining data from the front- and backend, and adding additional context both on back-end to make fixing bugs easier.

I want to only get errors that are actually caused by my code. I want those errors to have added context that might be needed to help debugging like props passed to the component, etc. I want these errors to be tied to back-end API route & Server Action logs, so we can see if the true root cause of the bug is in the back-end, and immediately fix the actual root cause.

I just want to see a graph of where there are errors, Which API routes or Server Actions are erroring out. When I view a request, I want it to show exactly what happened, for instance; what database items were created, or what errors happened if a database `create` query failed, and what data I tried to create in the database etc. And I want to get all of these insights without having to manually input a bunch of logging all over my code-base, because let's face it, it just aint' gon happen.

So that’s what we’re building. A full-stack error monitoring tool that deeply understands your code-base, provides observability to the level of React components, automatic context from the tools you use such as Supabase, Prisma, Drizzle, Zustand etc, and where front-and backend is beautifully merged together to give a clear understanding of what went wrong.

Help us bring the developer experience of error monitoring and bug fixing to 2024 standards. Contribute on our GitHub, or suggest ideas to our roadmap via DM on Twitter, or just join our Discord and we can have a chat!