Eric Brandes

We are unlikely to add additional language support to TrackJS. And it's not just because of our name!

Learn from our mistakes: be careful when using VC funded companies as vendors or important parts of your stack.

Unprofitable companies, like Flexport and Splunk, are a risk for their customers because they can radically change or close down entirely. What about TrackJS?

TrackJS now offers Saved Filter Notifications - create custom alerts for specific error scenarios. Filter by message, user, URL, or other criteria, then get notified when those errors spike. Perfect for monitoring critical issues, API problems, or VIP user experiences.

Ad blockers are blocking TrackJS domains, causing you to miss JavaScript errors from 25-50% of users. Our new domain forwarding feature lets you use a custom domain (like errors.yoursite.com) to bypass ad blockers and capture all your error data.

We recently needed to parse and modify some query strings while building Request Metrics. Query string parsing has never been pleasant in .NET, has it improved in .NET Core? We were familiar with HttpUtility.ParseQueryString() for the task, but that API has a major landmine.

We store all of our JavaScript error data in a large Elasticsearch cluster. This lets our customers slice and dice their error data in realtime, and perform full text searches over it. We push Elasticsearch to its limit, and we recently started querying more data for some of our core pages.

We understand the value of JavaScript error monitoring here at TrackJS. Consequently, we run TrackJS on all of our own web properties to log our JS errors. We’re dilligent about fixing errors as they happen, and most issues are caught in development environments, or immediately in production. Ho...

We recently released a significant update to the way users filter and explore their error data. I want to discuss how we built it, the tools we used, and how we’re doing things “differently” than everyone else.

Dealing with noise is the biggest problem in client-side error monitoring.

Unless you were hiding under a rock, you probably heard about the “event-stream situation” on NPM this week. TLDR: the original maintainer of the event-stream package was tired of maintaining it. He handed over the reins to a different developer, who promptly injected malware and released a new ...

These days it’s common to release new versions of a web application daily, or even multiple times a day. At any given time there could be multiple versions of a code base running live in production. A new version might be getting soak tested on a pilot server, while the previous stable version ...

At TrackJS we pride ourselves on our pragmatic approach to software development. We’re cautious of making changes - every change must be weighed not only by its reward, but also its risk. We prefer to avoid big sweeping changes if possible. Smaller, incremental changes are typically our goal. ...

I recently appeared on Dave Rael’s Developer on Fire podcast. The show focuses less on technical minutiae and more on the developer as a person, and their approach to adding value. I got to talk a little bit about how I think a developer can add value, and wanted to elaborate a bit more. When ...

Large web applications are almost always built by multiple teams. When the scope or scale of an application grows, there’s just no way a single team can be responsible for the entire thing. How you divide an application in to teams effectively is beyond the scope of this post, but for now let’s ...

“The only thing constant is change.” A silly platitude, but if you’re a frontend developer you can empathize. If it’s not JavaScript frameworks that are changing, it’s the language itself. If it’s not the HTML spec changing, it’s the protocol the markup is served with. The web moves fast. Th...

I built my first website in 1995. It was a simple affair consisting of markup I wrote with notepad.exe. Deployment involved FTPing the files to GeoCities. The code is long gone, but that site would still render the same with Chrome in 2018 as it did with Netscape in 1995. Heck, even the first...

The ability to set the status of an error is our most commonly requested feature. Customers want to mark errors as fixed, or one team member wants to let the rest of the team know they are investigating an issue. There’s hundreds of reasons to set the status of an error, and until today it was ...

One of our biggest challenges is helping customers make sense of their JavaScript errors. Web applications produce a staggering number of errors, but not all of them are relevant. We have great tools like ignore rules and error groupings to help curate the data, but some noisy errors still get ...

It’s common to have JavaScript error messages that are almost identical, but differ by a url segment or identifier. These can be noisy, creating dozens (or hundreds) of different groupings for the same bug. To clean this up, we’ve introduced Grouping Rules that allow you to define your patterns a...

We’ve been busy building new features and wanted to take a few minutes to highlight some of them. Often we’ll soft launch a feature without much fanfare to make sure it’s working as intended, so sometimes it’s not obvious when new functionality appears. So here’s some of the cool new things we’...

Ever since jQuery introduced deferreds, developers have used promises to manage asynchronous control flow. (I know, I know, promises pre-date jQuery, but that’s when they went mainstream). In the years since their introduction promises have been standardized and are now being implemented nativel...

With the proliferation of JavaScript transpilers, sourcemaps have become an integral part of the front-end development. If you’re using Angular 2, React, Om, Elm, or others, there are huge advantages to debugging by using sourcemaps. We’ll show you what they are, how to use them, and some things...

One of the hardest parts of client side error tracking is giving the customer meaningful signal from a sea of noise. The internet is a hostile place, and errors occur for all kinds of reasons. We noticed that sometimes, even with all of our filtering, it was possible for certain errors to slip ...

One thing we’re constantly striving to maintain at TrackJS is a high signal-to-noise ratio. Logs filled with meaningless errors hide significant problems from developers and admins. If there’s too much noise, the important errors fall through the cracks.