My errors are gone w̶i̶t̶h̶o̶u̶t̶ with a trace
Dan Mindru is a Frontend Developer and Designer who is also the co-host of the Morning Maker Show. Dan is currently developing a number of applications including PageUI, Clobbr, and CrontTool.
I can’t imagine another product where I go from “I probably don’t need this” to “I am adding this to all my products.” That’s what Sentry did to me.
Can you imagine how many things a product needs to get right to change someone’s mind without some sort of human interaction or sales pitch?
I resisted this for the longest time because I thought this was not a product for the small entrepreneur, the bootstrapped company, or the indie maker. Boy, was I wrong.
Let me tell you how I came to love Sentry.
The backstory and fundamental issue with raw logs
I’m running 5 different paid products (and a dozen tools/open-source projects, such as Page UI, Clobbr, Crontool, etc.). There’s some pride in bootstrapping these, but it comes with a huge cost.
The size of the “team” is, well, one. I, myself, and I have to ensure they are all running smoothly, they are performant, and that I have a good handle on support requests when they come in. My time is extremely limited and every minute I spend understanding what is happening can be spent on marketing, sales, and growing the products instead.
Navigating through raw logs and trying to figure out what went wrong is the complete opposite of what I should be doing. Yet, before I used Sentry, I would spend hours (if not days) every month sifting through logs and trying to understand what went wrong.
The worst part is that this would be in reaction to a customer’s angry email, and more often I did not have much of a clue about what crashed. It’s not a good feeling some days.
When you care deeply about the product you’ve built, this can derail your day and throw you on a wild goose chase that takes away all your motivation for that day.
So here I am, after spending hours trying to trace the root cause of a critical issue. Here’s what I went through:
- Identifying the serverless function that crashed
- Finding the part of UI that triggered it
- Tracing breadcrumbs of methods that led up to the call
- Adding new context to logs to understand what payload caused the issue
- Finally, identifying a 3rd party API call that crashed and trying to understand why
Here’s what I was looking at
Inspecting that was a pointless exercise that only increased my frustration after hours of being sidetracked. This is not even a host problem because wherever you deploy—GCP, AWS, Azure, etc.—the experience is similar: a sea of logs with an overly complicated UI with many filters that are hard to understand; and forget about using them anyway because you will need to end up using LogQL™ or some sort of proprietary log query language that, frankly, is the last thing I want to do when I have an angry customer waiting for a reply.
So this is all I have: I know where the error happened, and I know what caused it. I don’t know what the 3rd party response is, and no matter how much context I try to add, I can’t see it in the logs.
Let’s see how it goes with Sentry.
The new standard
This is when, out of desperation, I decided to install Sentry. I know it from my consulting work and have been working with it occasionally in other systems, usually fixing bugs for clients.
I remember thinking to myself: “This must have been difficult to set up; it captures pretty much everything that’s going on.”
So I gave up on the rest of my day and bit the bullet. Turns out, if I had done this hours before, I could have avoided all this frustration.
The new DX Standard
If you ever installed logging or error-tracking tools, you know very well that adding those can be an adventure that lasts anywhere from a few hours to many days.
How about minutes? Sentry’s install wizard does just that.
If you ever build a CLI, this should be your Northern Star. It’s smooth, it asks the right questions, and does not require you to do anything manually.
The new monitoring standard
This process above is completely backward. I now realize that it is possible to jump straight to 5. Today I don’t need to wait for the customer email, I get an email from Sentry that includes:
- UI Session Replay
- Context
- Traces
- Exact line that caused the error (with highlighted code)
- 3rd party response
Right in my inbox.
This is my new standard and I think it should be yours too. Here’s why.
The new “log” UI standard
Here’s how a typical log UI looks like today:
Can you find the panel with the log entry? It’s just between the 3 search boxes.
Here’s how your issue UI should look:
And when you click on a specific issue, the details should look like this:
For a long time, we’ve been accepting a poor user experience when it comes to logs. I get it, it’s a difficult fish to fry. But in my opinion, most companies are focusing on the 80% we never use instead of the 20% we use daily. Granted, it is not the same thing, but since I added Sentry I never opened my Cloud providers’ logs again.
So having spent some minutes installing Sentry, I wasn’t prepared for what was to come next.
Resolving the issue
The rest of the story is one of those that you read and think, “This is too good to be true”. If I was the reader, I would feel the same. You need to trust me on this, this is my complete, raw reaction and it comes from the heart. And I brought proof ― as soon as this happened, you bet I wrote about it.
Here’s how it happened:
- I deployed with Sentry installed
- I reproduce the issue in the UI
- I get an email from Sentry
- I navigate to the issue. Here’s what I see
- I see I am missing a permission for this account, thus the reason why the 3rd party failed
- I add the missing permission
- The issue is resolved in about 5 minutes
That’s it. That’s the entire story. That’s why I will never go into production without Sentry.
Getting wiser, fast
The great part about Sentry is that it has a ridiculously low entry barrier.
You don’t need to know much about the product and the installation is dead simple. However, this product has a way of revealing advanced features right when you need them.
I am much wiser now and can share a few great tips.
Adding context via attachments
As I mentioned before, sometimes getting the context is time-consuming business.
Meet Sentry attachments.
This feature allows you to attach files to an error message and it has proven to be a massive time saver.
You don’t need to look up a user, dig through the database, and try to piece together what a method’s payload is. You have it all front and center with a handy preview. This is just something you have to experience to truly appreciate.
Seeing what led to an exception with traces
For systems with many microservices or a plethora of tasks, this overview is an absolute goldmine. It helps find concurrency issues as well as understand the performance of each step.
Finally, it makes it SO easy to reason about an exception by understanding the wider context. I don’t know of any service that does this so well. Frankly, this view is a work of art.
Treating performance as a critical UX factor
As developers, we probably work on a beefy machine with more cores than you can count.
The fact is, our users don’t. We should treat performance as one of the most important components of user experience. If you have worked in e-commerce, you know that even 500ms could cause a huge dip in your conversion.
After a while of using Sentry, it was kind enough to point out what a horrible job I’m doing optimizing performance. Putting 1 + 1 together, I realized this is also affecting my SEO.
I recommend keeping an eye on that and constantly optimizing performance. Your users are going to thank you as well as your finance department.
Make it easy for users to give you feedback
One of the best things you can do for your product is to have a clear, easy-to-use Feedback/Report button prominently shown across your website, app, docs, and everything in between. Of course, with Sentry, that’s just another integration.
These will probably be the best 5 minutes you’ve spent today.
Wrapping up
Reflecting on this after a few months have passed, I can only come to one conclusion.
I should have tried Sentry a lot earlier.
In the current landscape of 100 SaaS offers hitting you left and right, I became reluctant to add yet another service to my apps.
On the other side of this: I have a more stable system, better user experience, better performance, and most importantly: I sleep so much better at night knowing Sentry is watching over my sloppy code.