Atatus - Real User Monitoring

All large-scale web applications need some sort of browser monitoring to know about the user experience with JavaScript in the browser. If you care enough to want to monitor your users’ in-browser experience, you probably also are the sort of company who cares deeply about security, privacy, and performance.

Browser / Real User monitoring can be an amazing window into your users’ experience, but it also typically presents trade-offs on all three fronts: collecting data, sending data to the server and visualizing it.

We built Atatus with client-side browser monitoring in mind, and has built a flexible graphing, monitoring and alerting tool-chain. It requires only two line of JavaScript code to collect that data and post it to our server. The negligible amount of overhead required to load the JavaScript results in a significant return of actionable data.

Atatus Browser monitoring measures page load time, also known as real user monitoring (RUM), but it goes far beyond that to measure:

• Individual page performance
• AJAX requests performance
• JavaScript errors
• Alerting

Individual page performance

Page load time is a vital metric to understand how fast the web site content is loading for end users. Page load time is represented in two numbers (usually one for the back-end application and network time, and the other for browser rendering and sub-resource loading time).

We take these timings and graph the deltas between them in a stacked graph. We have an overall graph (below), and we also segment the stats by a few other metrics, like browser (Safari, Firefox, Internet Explorer) and page. Atatus also allows you to view details by page load time distribution, average page load time, and throughput.

We still support some older browsers that don’t implement the Navigation Timing API, so we also collect a simulated time-to-window-load number, or “cross-browser load time.” This is calculated in JavaScript — the time between the start and the window load event.

AJAX Monitoring

AJAX is everywhere. Single page web apps do it and it’s increasingly rare to find a traditional web app that doesn’t have a significant AJAX component. AJAX takes the place of a standard browser navigation, but it’s usually about 1000ms faster. We found that increased visibility into AJAX to be extremely helpful for quantifying the effect that performance problems have on the end user experience.

Atatus wraps the XMLHTTPRequest to capture all AJAX request timings. Atatus help you to visualize response time, throughput requests per minute (rpm), and average data transfer rates per request can help identify timing problems. You also see the error status codes related to the requests provide information about the return behavior from the call

JavaScript Errors

Another major focus of our browser monitoring is JavaScript errors. Better error tracking has been one of our most useful features. Mostly deployment process varies from small, frequent deploys over big-bang releases, and small changes or urgent fixes. The time between committing changes and having them deployed to production can be only a few minutes. Deploying small sets of changes helps developers reduce the risk associated with each deployment, but the higher frequency means that we’re unlikely to do exhaustive cross-browser regression testing before each deploy, so Atatus error monitoring helps to have monitoring to detect when things go wrong.

Atatus provides enough information to reproduce JavaScript errors to help resolve them:

• You can add user information, custom data, and tags to the error. You can control what exceptions we report on, as well as how we report on them. You can filter out JavaScript errors in the Atatus dashboard by user, tags, etc.
• Obviously, we provides the typical reporting information: stack traces, url, browser/OS versions, user agent string, frequency, etc. Along with, we show time line of user actions happened that leads to an error.

JavaScript error reports are always a bit noisy — browser extension code can trigger errors that look legitimate; nightly or experimental browser builds may have broken APIs, etc. An important part of keeping your JavaScript error reports actionable has been to filter out any errors you don’t think are related to our code. Most of the time, the number of errors we filter is larger than the number we keep and send to Atatus. We filter anything with a browser extension file in the stack trace, since it’s likely related to the extension behavior, and anything that matches a blacklist of specific errors we’ve tracked down (e.g. a particular popup blocker extension). There are always a handful of one-off errors that may not be worth digging into, but you can usually spot real problems by looking for errors happening multiple times per hour to more than one user.

At this point, some might ask, Why not just write browser tests, so you can catch errors and regressions before you deploy them? It’s a great question — I definitely don’t see client-side monitoring as a replacement for integration or acceptance tests. But tests almost never capture the variety in real production data or the variety in real users’ browser versions. Atatus Browser monitoring captures all of these by default. Plus, tests only capture errors when you run them, which is usually when you’re committing code changes, but the environment around front end code changes all the time. You always want to know about new errors your users are running into, regardless of whether they come from the deploying new code or from the Google Chrome team rolling out a new browser version.

Alerting

We supports most popular integrations: Slack, VictorOps, PagerDuty, Campfire, Datadog, Flowdock, HipChat, OpsGenie, Asana, and Webhook. Atatus notifies you for new JavaScript errors and performance issues that you care about the most, so you can address the underlying problems before they reach your end users.

Atatus also support ticketing integrations such as JIRA, BugHerd, Lighthouse, Pivotal Tracker, and YouTrack. You can directly create an issue into your favorite issue tracker from Atatus JavaScript error dashboard.

What’s Next?

While our browser monitoring tools give you deeper visibility into our users’ experience of your web app, we’re really excited to bring more features to Atatus. Singe page app(SPA) monitoring is the next step we like to add on our features to gain more visibility into your SPA(e.g. Angular, React, Ember) apps.

Atatus makes performance monitoring and error tracking easier so you can get back to building features for your customers.

Try Atatus Browser Monitoring with free 14 day trial – no credit card required. If you have any questions, we’d love to hear from you.

We recently introduced Node.js Performance monitoring. Checkout our blog about it.