Caching is one of the big draws for people using the Next.js framework. Its on-by-default, “just works” nature sets you up for high performance applications right out of the gate. However, improving web performance comes at the cost of a complex caching system. This complexity is a source silent errors in the form of stale and incorrect data. Next.js does its best to choose the right caching behavior for each page. Sometimes, it chooses wrong, resulting in unexpectedly stale pages or even pages that are slower than they should be.

Next.js caching is remarkable in that it caches so many things in so many places. Everything from fetch requests to rendered HTML and RSC payloads for hydrating an entire page are cached when possible. To add to the complexity, Next.js caches at many levels with build time, server and browser side caches.

Note: All examples use the App Router and Next.js version 15 unless otherwise stated. However, much of this applies to version 14 as well.

Understanding NextJS Caching

What Does Next.js Cache?

Next.js does its best to cache as much as it can for as long as it can. There are three main things that are cached: fetch() response data, rendered HTML and React Server Component(RSC) Payloads.

Where Does Next.js Cache Data?

Next.js caches different kinds of data in all layers of the application using four main mechanisms. The Data Cache, Request Memoization and the Full Route Cache are all used to cache data on the server while the Router Cache caches data in the browser. Not all caches are populated at run-time. The Full Route Cache even caches data during the build process by becoming part of the build artifact.

All these different data types, mechanisms and locations make for some confusion. You can generally determine where and what your data cache is caching your data by considering the kind of data you’re working with:

How Does Next.js Handle Stale Cache?

Next.js uses a “fetch for next time” strategy when handling stale data. This results in the user seeing some stale information. The cache is only checked for stale data when a request is made for that data. When stale data is discovered, it is returned as-is while fresh data is fetched in the background. This keeps pages fast, but causes expired data to display to the user at least once before it is reloaded.

fetch() Caching

If there’s one thing Next.js loves caching, it’s data from API calls. Generally speaking, requests to external API’s are made using javascript’s built-in Fetch API. Next.js wraps native fetch() to automatically store calls and return them from the cache.

Requests are cached at run-time on the server and also at build time when rendering static pages. Fetch caching is performed by two separate mechanisms within Next.js with the difference being how long the cache is valid.

Don’t use fetch? Some things like SQL and other data sources have their own client libraries which don’t use fetch(). Next.js provides a cache() function for these situations. cache() allows any expensive or slow call to be cached while still benefiting from Next.js’s builtin caching behaviors.

Two mechanisms are used to cache fetch responses depending on whether the data is for same-request caching a longer term caching:

Same Request Caching

Duplicate requests made within a single page load are cached by Next.js Request Memoization. This sounds fancy, but it’s just a per-request cache for fetch() and cache() calls. It lets you make requests in different components without worrying about duplicated requests. When Next.js sees that multiple requests share the same destination and arguments, only one request will be sent to the API. The other calls will be returned directly from the Request Memoization cache. You no longer need to pass a single response data from parent to child components to improve performance! The data in the cache will not be re-used once the request lifecycle has ended.

Cross Request Caching

When data should be used in multple requests, Next.js stores it in the Data Cache. The Data Cache saves fetch response data just like Request Memoization, but reuses responses in more than one page load. A cached response can be valid forever, invalidated after a specified amount of time, or invalidated on demand.

HTML Caching

HTML for static pages is pre-rendered during the build and stored in the “Full Route Cache” as part of the build artifacts. This HTML is returned on initial page load to quickly show the content of the page. Client side components are then re-hydrated to finish building the page.

Just like fetch() caching, cached HTML can be valid forever, invalidated after a specified amount of time, or invalidated on demand depending how it is configured. The Next.js server renders and caches HTML at runtime in cases where the cache is configured to expire.

React Server Component Payloads (RSC)

React Server Component Payloads (RSC) are also generated at build time or run-time on the server. Cached RSC payloads work very similarly to cached HTML, but are used for subsequent Single Page Application (SPA) style page navigations. After the initial full page load, Next.js navigates to new pages by using the browser’s History API and DOM manipulation.

What is a RSC payload? RSC stands for React Server Component. RSC payloads describe everything about a page and contain pre-rendered Server Components, client component placeholders and props passed to client components from the server. Next.js uses this data to hydrate new pages without doing a full page load.

RSC payloads are cached by two mechanisms depending on where the payload is cached:

The Server

The Full Route Cache stores RSC payloads and pre-rendered HTML. The server uses it to quickly return pre-built RSC payloads to the browser. Those payloads are generated at build time for static pages. For pages that are re-validated periodically, the payload is rebuilt and stored in the cache at runtime by the Next.js server.

The Browser

RSC payloads are the one data type that Next.js also caches in the browser. These payloads are stored in the Next.js Router Cache. The Router Cache re-uses RSC payloads when going back and forward through history and when navigating to a new page whose RSC payload has been pre-fetched. No request is made to the server when the cache has the necessary payload.

Static Pages as Cache

When coming from other JavaScript frameworks, Next.js Static Pages are rather confusing. Static pages effectively work as a cache but they cache the final HTML not just the data that was used to build the page.

To add to the confusion, these static pages are executed and cached at build time. Next.js automatically opts in pages to static caching when it thinks they do not use any dynamic inputs. As an example, this basic Next.js page is static, resulting in surprising behavior:

export default async function Page() {
    return <div>
        <h1>This page is statically rendered</h1>
        <div>
            {/* The rendered date will never change! */}
            {/* In fact, the date displayed will be the date the application was built! */}
            Rendered at: {new Date().toString()}
        </div>
    </div>
}

Common Caching Examples

Although Next.js tries its best to make the best caching choice for each page, it will be wrong sometimes. In those cases, you can specify explicitly how you would like pages and data cached.

How to Force a Page To Render Dynamically

A page can be configured to render dynamically even when Next.js heuristics have determined it should be a static page:

// Tell Next.js to always render this page dynamically
export const dynamic = 'force-dynamic'

export default async function Page() {
    return <div>
        <h1>This page is dynamically rendered</h1>
        <div>
            {/* The rendered date will update every page load! */}
            Rendered at: {new Date().toString()}
        </div>
    </div>
}

How to Force a Page To Render Statically

Forcing a page to render statically is much less common, but Next.js has a configuration for it when needed:

// Tell Next.js to always render this page statically
export const dynamic = 'force-static'

How to Re-render a Static Page After A Specified Time

Some pages don’t need up to the second updates, but just need to be refreshed occasionally. Next.js can be told to occasionally refresh a static page.

// Tell Next.js to re-render this static page every hour
// In seconds, 60 sec * 60 minutes/hr = 3600 seconds
export const revalidate = 3600

How to Rerender a Static Page On Demand

Next.js clears the cached page HTML and RSC payloads and re-renders them when a page’s path is revalidated.

Note Caches cannot be cleared inside render functions. revalidatePath() must be called inside a Server Action or Route Handler.

// Inside a Server Action or Route Handler
revalidatePath('/path/to/static/page')

How to Enable fetch() Caching

Starting in Next.js 15, fetch requests are un-cached by default. You must opt into caching even when making GET requests. In Next.js 14 and below, only GET requests were cached by default. Use the 'force-cache' option when making a request that should be cached:

export const dynamic = 'force-dynamic'

export default async function Page() {
    var response = await fetch('https://api.example.com/...', { cache: 'force-cache' })
    var data = await response.json()

    return <div>
		    This fetched data is cached by Next.js: {data.exampleString}
    </div>
}

How to Disable fetch() Caching

Some requests should never be cached. Use the 'no-store' cache setting to disable caching for that request:

// Tell Next.js to never cache this fetch request
var response = await fetch('https://api.example.com/...', { cache: 'no-store' })

How to Cache fetch() Responses For A Specific Amount of Time

Requests don’t have to be cached forever. Next.js can cache requests for a certain amount of time before re-fetching them. The Next specific revalidate setting specifies the lifetime of the cached response:

// Tell Next.js to cache this fetch request for a minute
// The setting is in seconds
var response = await fetch('https://api.example.com/...', { next: { revalidate: 60 } })

How to Clear fetch() Cache On Demand

Sometimes your application knows when data has become stale. In those cases, you can tell Next.js to clear the cache when needed. You must tell Next.js which cached data should be cleared. Data can be cleared by the path of the page or by tags placed in the fetch requests.

How to Clear Cached Data By Page

All cache used by a page can be cleared using the page’s path.

Note Caches cannot be cleared inside render functions. revalidatePath() must be called inside a Server Action or Route Handler.

// 1. Make a cached fetch() request on page '/my/page'
var response = await fetch('https://api.example.com/...', { cache: 'force-cache' })

// 2. Later, inside a Server Action or Route Handler
revalidatePath('/my/page')

How to Clear Cached Data By Tag

Clearing by tags lets you re-fetch a type of data regardless of what page it was loaded on.

Note Caches cannot be cleared inside render functions. revalidateTag() must be called inside a Server Action or Route Handler.

// 1. Make a cached fetch() request on any page
var response = await fetch('https://api.example.com/...', { cache: 'force-cache', next: { tags: ['example-api'] } })

// 2. Later, inside a Server Action or Route Handler
revalidateTag('example-api')

How to Clear All Cached Data

The entire Next.js cache can be cleared by revalidating the root path:

// Inside a Server Action or Route Handler
// Clear ALL cached data
revalidatePath('/')

How to Cache Data When Not Using fetch()

Next.js can cache data even when fetch() is not used to retrieve it. This is commonly used for database requests. Code must opt-in to this caching by using the react cache() function:

import { cache } from 'react'
import { expensiveCall } from 'lib'

// Wrap our expensive call in react's cache function
export const getItem = cache(async (id: string) => {
  const item = await expensiveCall(id)
  return item
})

Common Problems with Caching in Next.js

If this post didn’t make it obvious, Next.js caching is pretty complex. This complexity causes silent errors in the form of stale content from over caching and poorly performing pages from under caching. Some of these problems are pretty easy to stumble into:

Changes To Caching Behavior in Next.js 15+

Next.js version 14 and below cached fetches and GET route handlers by default. This resulted in unintuitive default behaviors. Because of developer confusion, version 15+ does not cache fetches or route handlers by default. Fetch calls and route handlers must now opt-in to caching.

Users See Stale Pages And Data in Next.js

Stale data will be displayed to users at least some of the time when a page uses any of Next.js’s caching features. This is caused by two Next.js caching behaviors. First, stale data is only checked when a page is requested. And second, to refresh stale data, Next.js returns the stale data for the current request and fills the cache with new data later in the background. Read more

Next.js Pages Rendering Statically

All pages are treated as static by default. Next.js has heuristics to detect dynamic pages, but they are not perfect. When the heuristics fail, Next.js renders static pages at build time and never again. Here’s an example of a static page causing unexpected results. This issue is resolved with 'force-dynamic' which tells the page to render dynamically.

Next.js Always Caches Duplicate Fetch Requests in a Single Page Load

In rare instances, a page makes the same request multiple times, expecting all requests to be sent to the server. Next.js’s “Request Memoization” cache will always cache all requests after the first!

export const dynamic = 'force-dynamic' // Always render dynamically

export default async function Page() {
    // This request is not cached by default (In Next.js 15)
    var response = await fetch('https://api.example.com/data')

    // Request Memoization will always return the cached result from the first request
    var response2 = await fetch('https://api.example.com/data')

    return <div>I fetched some data!</div>
}

Avoid ALL Next.js fetch caching by using the unwrapped fetch:

var response = await fetch._nextOriginalFetch('https://api.example.com/data')
var response2 = await fetch._nextOriginalFetch('https://api.example.com/data')

Next.js Making Requests For Every Visible Link

Next.js has very aggressive client side link prefetching. All links visible in the browser’s viewport are prefetched from the server. This can result in a large number of requests being made as soon as a page finishes loading. While beneficial for

Remember the Prod Build! This behavior does not occur in development mode.

export default async function Page() {
    return <div>
        <h1>All these links will be prefetched by Next.js as soon as the page finishes loading!
        <div>
            <Link href="/here">go here</Link>
            <Link href="/there">go there</Link>
            <Link href="/everywhere">go everywhere</Link>
        </div>
    </div>
}

Next.js Production Builds Behave Differently than Development

When running in development mode, Next.js does not cache as heavily as in the production build. This can cause a page to work perfectly during development but then be cached too heavily when run in production. Be sure to test caching behaviors in Next.js production builds when testing cache behaviors.

# Running in development mode is quick and easy, but doesn't show full caching behavior:
npm run dev
# -or-
next dev

# Running a product build will enable all Next.js's caching features:
npm run build
npm run start
# -or-
next build
next start

Build Next.js Apps with Confidence!

Bugs are inevitable, even in modern frameworks with fancy caching features. Having a system to automatically capture and report errors when they happen is key to having confidence in your development cycle, and your products.

TrackJS error monitoring fully supports Next.js, and all other JavaScript technologies. Built by developers for developers.

Nothing changed in your code. All of a sudden, a tidal wave of errors start happening for Microsoft Edge users. What the heck happened?

On August 28th, 2019, many TrackJS customers saw a sudden surge in errors from Microsoft Edge browsers: Failed to construct 'Request': Invalid Argument and Failed to execute 'fetch()' on 'Window': Invalid argument".

Our Debugging blog series explores symptoms, causes, and solutions to common JavaScript errors.

The spark that set off this error was a change in the Facebook sdk. Specifically, this snippet of code from their sdk.js:

fetch(url, {
    referrerPolicy:"origin",
    mode:"cors",
    credentials:"include"
});

In this of call to fetch, facebook is passing referrerPolicy. However, as noted in the compatibility table, the referrerPolicy has “No Support” on Microsoft Edge.

“No Support” is an understatement.

Root Cause

fetch can be called with a Request object. However, all known versions of Microsoft Edge, through 18.18975, this will throw an error if referrerPolicy is passed as an option.

For example, this snippet of code will throw an error in Edge:

var req = new Request("https://example.com/", {
    referrerPolicy: "origin"
});
//=> Failed to construct 'Request': Invalid Argument.

The referrerPolicy property was added to the standard in June 2018, so it is understandable that Edge does not yet support it. However, the fact that Edge throws indicates that Microsoft’s implementation of Request is leaking out.

We have opened an issue with Microsoft about this issue. However, as they will soon be switching to the Chromium engine, we expect it to go unresolved.

This bug may also manifest as the error Failed to execute 'fetch()' on 'Window': Invalid argument. if you pass the referrerKey option to fetch directly. This error will not be thrown, however, it will come as a Promise rejection.

Workaround

ReferrerPolicy specifies whether the current URL will be provided on the Referrer header for the request. MDN has some great examples of how this will be applied.

While Facebook will need to resolve the issue on their sdk, you may still have this error in your own code. Fortunately, the most common use cases for the policy can still be achieved.

Option #1: Don’t Use Request

The issue only manifests itself using the Request object as an argument to fetch. You can pass the same parameters directly the fetch. For example,

fetch(new Request('/', {/*options*/}));
// becomes =>
fetch('/', {/*options*/});

Option #2: Use Default referrerPolicy

Simply don’t set the referrerPolicy for the request. This will default to the page’s policy and send along appropriate information. You will need to set the referrerPolicy header appropriate when serving your web pages.

Option #3: Explicit Set Referrer

Rather than relying on the policy to decide what to send as the origin value, you can control how much information is passed along with the referrer property.

For example, if you want to replicate the "origin" referrerPolicy, you can use the following code to strip path information out of the referrer by setting it to the root of your domain.

fetch("https://example.com/", {
    referrer: "/"
});

Another example, if you want to replicate the "no-referrer" referrerPolicy, you can remove the referrer all together by setting it to empty string.

fetch("https://example.com/", {
    referrer: ""
});

Browsers and third-parties can create errors on your website when you least expect them. Production error monitoring from TrackJS will let you know when someone breaks your site. Give it a try and let’s build a better web, together.

NextJS is the hot JavaScript framework right now, and like all JavaScript, it can cause quite a few bugs on both the client- and server-side of your applications.

One of the most powerful features of NextJS is enabling you to use your code, templates, and patterns across both the server and the client. NextJS will mostly figure out the most efficient place to run. This is super powerful and makes NextJS applications feel very fast compared to strictly client-side rendered applications.

However, that does mean you need to handle errors and exceptions in both the client-side browser environment as well as the NodeJS server. There are two slightly different ways to make sure you monitor all the ways your NextJS application can fail.

Client-Side Error Handling in NextJS

NextJS is built on top of React and utilizes the ErrorBoundary concept to handle errors at different levels of the application. This could be useful if you want to have different error screens for different parts of the app.

Of course, we can’t predict where errors will occur, so we also need a “top level” error handler to catch everything. This is also the best place to plug in an error monitoring service like TrackJS. In NextJS, the top-level error handler is the global-error.tsx file in the root of app.

"use client";

import NextError from "next/error";
import { useEffect } from "react";
import { TrackJS } from "trackjs";

// Setup your error monitoring
TrackJS.install({...});

export default function GlobalError({ error, reset }) {

  useEffect(() => {
    // Capture an error
    TrackJS.track(error);
  }, [error]);

  return (
    <html>
      <body>
        {/* This is the default Next.js error component. */}
        <NextError statusCode={undefined as any} />
      </body>
    </html>
  );
}

The global-error.tsx file only runs in the client-side environment, so it needs to start with the NextJS "use client" directive.

Quick aside, the TrackJS agent has been using the custom "use awesome" directive for over 10 years now. Because, ya know, it’s awesome.

Most of this global-error.tsx is the standard boilerplate, with 2 additions: first, the call to TrackJS.install. This is where you can configure your instrumentation of the client-side to gather any additional context for your errors. This code will be run right away, regardless of whether or not an error occurs.

The other addition is the call to TrackJS.track within the useEffect. This get’s called by NextJS when an error actually has occurred in a production environment. Even if your error monitoring automatically captures errors (like TrackJS), sending the errors directly within the useEffect will provide better error data.

Don’t Forget! The global-error.tsx only runs in production builds. To test out your error handling, you need to build and start the project in production mode.

Server-Side Error Handling in NextJS

Some of your application code will also be run on the NodeJS server-side of NextJS. NextJS does a pretty good job of detecting most failures, and when it does, it routes the errors to the client-side where it will be recorded by the global-error.tsx file.

But it doesn’t catch everything.

There are several situations where NextJS can blow up on the server and not return anything to the client. How can you detect when those errors happen?

There is no app.tsx or other root application file to plug into. However, the root layout.tsx file is one of the first things that runs on both client and server, so it’s a great place to add other application-level configuration and calls.

import type { Metadata } from "next";
import { TrackJS } from "trackjs-node";

// Setup your error monitoring
TrackJS.install({...});

export const metadata: Metadata = {...};

export default function RootLayout({ children }: Readonly) {
  return (/*your layout markup*/);
}

Your layout.tsx file will look much more complicated as it will have lots of general structure and layout for your application. But where I have the call to TrackJS.install is a great place to set up general error handling that will run on the server. An error monitoring system like TrackJS will attach itself to all the places a NodeJS application can fail and record errors automatically.

Note On the server-side, we use a trackjs-node package instead of the standard browser agent. You probably want to implement an isomorphic wrapper around both agents to centralize your configuration, which is very easy to do.

Build NextJS Apps with Confidence!

Bugs are inevitable, even in modern frameworks. Having a system to automatically capture and report errors when they happen is key to having confidence in your development cycle, and your products.

TrackJS error monitoring fully supports NextJS, and all other JavaScript technologies. Built by developers for developers.

As a Shopify theme gets more fully featured, it is likely that large amounts of JavaScript are being used to improve and expand the user experience. Making theme changes gets more nerve wracking as the amount of code increases. Did my sales go down because I broke something with the last JavaScript change?

If you’re worried about that next theme publish, it’s time to start monitoring user experiences for JavaScript errors. TrackJS makes error monitoring quick and easy to do!

How To Monitor JavaScript Errors In A Live Shopify Store

TrackJS is purpose built to monitor errors in production websites. It works with virtually every framework out there and Shopify’s theme system is no exception. This example starts with Shopify’s built-in “Dawn” theme and modifies it to include JavaScript error monitoring. That’s overkill for a simple theme built by Shopify, but the concepts should apply to your custom theme as well.

Installing the TrackJS agent is the only step needed to start tracking errors:

1. Get Agent Install Snippet

Copy the “global” agent install snippet from your TrackJS Dashboard’s install page. If using TrackJS Applications, get the application’s snippet from the application management page.

Don't have a TrackJS account yet? Sign up for a free trial to get started.

2. Insert Snippet In Theme Layout (Install The TrackJS Agent)

The install snippet needs to be present on all of the store’s pages where JavaScript is run. If most pages contain JavaScript, a commonly used layout is a great place to start. For example, the Dawn theme has a layout found at Layout/theme.liquid which used almost everywhere.

The snippet can be inserted using the Shopify Admin site. In the admin site, navigate to “Online Store -> Themes”, click the current theme’s “…” button and click “Edit Code”.

Add the install snippet to the layout and save:

3. Verify The Install

If your store is not live, test the install by manually sending a JavaScript error. Insert the test code into the same layout, just after the install snippet.

<script>
    console.log("Testing TrackJS Install");
    TrackJS.track('Testing TrackJS in my Shopify theme!');
</script>

The test error will show up in the TrackJS Dashboard if everything is configured correctly:

Don't Forget! Remove this test code when finished.

Know When Customers Hit Missing Urls

The store now has a basic TrackJS setup that captures all JavaScript errors! But we can do more. Why not keep track of any time a customer lands on a missing page? This can be very important in cases where an important affiliate is still using an old product URL.

1. Modify The Main 404 Template or Section

In the Dawn theme, the content for 404 (Not Found) pages is contained in Sections/main-404.liquid. Most themes should have a similar liquid template. Scripts in this template will run any time a user lands on a missing page:

... existing template here ...

<script>
  window.TrackJS && TrackJS.track("Page not found: " + window.location);
</script>

2. Test A Missing URL

We can easily modify the address in the browser to test:

TrackJS should display the error within the minute:

Protect Your Whole Store

Themes may have Layouts and Templates that don’t use the main layout. The Dawn theme has a `gift_card.liquid’ template that doesn’t use the default theme layout for example. This prevents agent installation from a single code snippet. Using a theme snippet to centralize the TrackJS agent config makes it easier to install the agent in multiple layouts or templates:

1. Create A Theme Snippet

From the code editor, add a new snippet file to your theme at Snippets/trackjs-install.liquid. Copy the same agent install code used above into the file.

2. Render The Snippet

Now the agent can be installed anywhere it is needed with a single line in the <head> tag:

<head>
  <!-- ...existing stuff... -->

  {% render 'trackjs-install' %}

  <!-- Other scripts should come after the TrackJS Agent install -->
</head>

Our Dawn theme.liquid and Templates\gift_card.liquid now look like this:

Make It Production Ready

At this point, TrackJS is in a fully supported, production ready configuration. However, there a few more things you may wish to do for extra production polish. The Shopify code editor has some opinions about our current setup:

Use The Shopify CDN

While the TrackJS script agent is served by a globally available CDN, the Shopify CDN can be used as well. This has the advantage of reducing your external site dependencies.

1. Download The TrackJS Agent

Save the TrackJS Agent Script to your computer.

2. Add The Agent To Theme Assets

Add the downloaded t.js file to the theme assets at Assets/t.js. If using Shopify’s online code editor, click “+ Add a new asset” in the Assets folder.

3. Update TrackJS Install Snippet

Tell the theme to use the new Shopify CDN location:

<!-- Replace this script tag... -->
<script src="https://cdn.trackjs.com/agent/v3/latest/t.js"></script>

<!-- ...With this: -->
<script src="{{ 't.js' | asset_url }}"></script>

Use Async Script (Optional)

We do not recommend async script loading the agent, but it can be done if a store’s page performance is the top priority. Enabling async will result in the TrackJS agent missing errors that occur during page load. These errors can be very important because they may be ruining the initial display of the page. Replace the agent install snippet with an async enabled version:

<script>
    window._trackJs = {
        // Use the same options that were passed to TrackJS.install()
        token: "{YOUR TOKEN HERE}"
    };
</script>
<script async src="https://cdn.trackjs.com/agent/v3/latest/t.js"></script>

Build With Confidence

Knowing whether you’re changes are affecting your customers takes some of the stress out of JavaScript changes in your themes. Now that TrackJS is installed on your Shopify store, errors experienced by customers will be captured in near realtime. Once captured, TrackJS provides additional context to help respond to and resolve issues before sales are lost or customer satisfaction is impacted. Happy Shopify-ing!

TrackJS is the best frontend error monitoring tool. It’s all we do and we do it well. To keep it simple we have just two different JavaScript agents. One for the browser, and one for Node server environments.

That’s it.

No other languages or platforms are supported. Just JavaScript.

Why Just JavaScript?

Most of our competitors support error monitoring for multiple languages, and we can certainly understand the initial appeal. But there’s a few good reasons we don’t, and probably will not, support additional languages in TrackJS.

Staying Small

We’re a small company. We want to stay that way. We like it that way. We can remain small and support our current surface area, so long as it’s just JavaScript.

As an alternative, consider the list of supported platforms for Sentry. That’s a huge list! Only a company with loads of employees could support all those platforms with any reasonable degree of competence.

Customer Support

Everybody who works at TrackJS is a very high level JS developer. All of us. When you contact support, your email goes in to a shared inbox that we all check every day. There’s no tier 1 support. There’s no ticketing system.

You will receive a prompt reply to your question from an engineer who knows everything about our product, because they build it. And everyone who works here has a minimum of 15 years of web development experience.

We pride ourselves on our customer support. It’s the best. Maybe the best of any company you’ve used, in any industry.

It’s that good.

But we can’t keep that level of support up if we add an additional 10 or 20 new languages. We’re not experts in Rust, so how could we hope to correctly monitor Rust errors, or write a Rust agent?

Actionable UIs

Every platform has different characteristics. Making JavaScript error reports useful from the web requires certain context. Things like screen size, browser name and version, console telemetry, user activity, etc. And it’s the same story on other platforms.

The problem is, the useful context you want to see in a JS error report is wildly different than the useful context you want to see in a Python error report.

Oh sure, there’s always some common ground. The user, the device, their location. But to make a good actionable UI that works well for Javascript and Python (and everything else) at the time is non-trivial.

In fact, we don’t think it can be done. Which is why we tailor made our UI for JavaScript errors. Everything about our UI is built on the idea of helping you find and fix your frontend errors. Stack trace parsing, sourcemap processing, telemetry gathering. All of it.

Frontend is Different

Frontend error monitoring is a different paradigm than backend. With frontend error monitoring you’re trying to capture errors that happen on remote devices out of your control. Oftentimes running a hodgepodge of incredibly untrustworthy interpreted code. And the errors often only happen in certain circumstances when users take specific actions.

Then all that data needs to be shipped over the internet back to a central location for processing and analysis. And there’s a lot of it. The error volume from frontend can easily be 10x or higher than backend.

Once you’ve got the data, you’ve got to figure out what the heck went wrong. Because things always go wrong in that kind of wild west environment, especially when end users are involved. You need all the telemetry and context you can get!

Contrast this with monitoring errors on a server in a language like Java. You own the hardware, you control all the code, and there are dozens of mature logging platforms for Java. In most cases you get reasonable stack traces that point right at the offending problem, out of the box.

Heck, at TrackJS, a huge percentage of our code is C#/.Net. We have a simple logger that pushes everything to an elasticsearch instance. We wrote a custom frontend to query it in about six seconds. We’ve never wanted more in 10 years.

The bottom line is you need a different kind of tool for frontend vs. backend error monitoring.

Summing it Up

We offer the best frontend error monitoring tool around. Seriously, we have the ratings to back that up. On top of that, we have exceptional customer support. But it’s all predicated on keeping our scope reasonable. We’d love to monitor all the languages and support every use case, but we’ve chosen a different approach.

We’ve decided to do one thing and do it well.

And that means we only support JavaScript.

TrackJS started ten years ago. To date, the only funding TrackJS ever received was the initial founder investment of $4,500 dollars (a whopping $1,500 per founder). Today, you’d call us a “bootstrapped” business.

We’re proud of that fact. It means there’s no outside investors. No one to make us build a product we don’t want to build. And no one that can pull the plug if the growth chart doesn’t look like a hockey stick.

Here’s one example of why that matters.

Picking a CDN Vendor

We host a JavaScript agent that our customer’s install on their sites. Bundling our script is fully supported, but lots of folks prefer to load directly from a CDN. That way, setup is a cinch, updates are instant, and CDN’s generally have PoPs closer to your users so performance is consistently good.

No One Ever Got Fired for Choosing AWS

We originally chose AWS Cloudfront as our content delivery platform. At the time, Cloudfront was very basic but fit the bill. It served our static content in a geostributed manner with performance that was, charitably, acceptable. The other nice feature was that you could easily configure it to use an S3 bucket as the content origin.

No One Ever Got Rich From Choosing AWS, Either

As our traffic grew, so did our AWS bill. And not just a little bit. At one point our CDN bandwidth bill was bigger than our dedicated server infrastructure bill! AWS might be reliable, but you pay a premium for everything.

Finding a New CDN Vendor

At the time there weren’t so many options as today. There were the big dogs, like Akamai, but you know that story.

TrackJS: “Tell me you’re an outlandishly expensive enterprise focused company without telling me”

Akamai: “Contact a sales rep for pricing”

We got to thinking. jQuery was all the rage back then; it was ubiquitous and used by millions of websites. Surely their developers would make smart technical decisions. Who did jQuery use as a CDN?

MaxCDN, the Glory Days

So we started using MaxCDN (née NetDNA). A content delivery network founded by a mixed martial arts fighter. It was simple, easy to configure, and much cheaper than Cloudfront. They had impressive clients (like jQuery) but they also catered to small businesses like ours. Their pricing was transparent and the performance was better than Cloudfront.

But nothing lasts forever.

A Dark Cloud On The Horizon.

In 2016 we get an email from the other (presumably less physically imposing) founder. Here’s some of it.

We started MaxCDN with the vision of creating an automated content delivery platform that customers would love… growing to 15,000 customers… We did this all with very little funding.

Yep, OK. That’s one reason we liked your company…

Out of the blue one day we got a call from Lance Crosby and his team who told us about their vision for StackPath

Uhh, who?

Joining StackPath is a perfect fit for my initial goal and obvious to me that it’s the next step in MaxCDN’s evolution.

Ope. Yep. So the MaxCDN guy needed a new boat.

Who the Hell is StackPath?

Well I’d never heard of StackPath, but I know an ominous email when I get one. Naturally the first stop was Crunchbase. Who are these guys? They came out of nowhere and bought our perfectly functioning CDN provider.

Here’s what their launch PR release says:

StackPath today emerged from stealth as the Security-as-a-Service company providing a path to a more secure Internet and announced a significant investment from ABRY Partners, a $4.3 billion private equity fund focused on investing in information and business service companies.

I don’t know anything about stealth (like they’re some kind of damned fighter plane?), but I can see VC/PE funded nonsense a mile away.

And it’s a lot of funds to be sure. They’ve raised just shy of $400 million since 2015. And unfortunately that means some lofty expectations. Expectations that our poor CDN will never meet.

Living on the Edge

We assumed the worst, but for awhile things were fine. We eventually had to migrate to their new “StackPath CDN”, which was probably just MaxCDN gear with a different domain, but otherwise worked OK. Funny enough, our monthly bill also went down. Turns out they were burning some of that investor money to keep bandwidth prices extra low.

But then, as inevitable as that hangover after your fourth fireball shot:

Best cloud computing platform? AWS, Azure, GCP and Cloudflare are all better known and more relevant. And you know what else? Every damn one of them has a CDN product.

The last paragraph of the announcement is particularly rich: “Akamai Technologies has acquired select StackPath enterprise customer CDN contracts”. Here’s the link.

“We look forward to welcoming these new enterprise customers and providing them immediate access to the agility and scale of Akamai Connected Cloud to create and deliver flawless digital experiences,”

StackPath sold their most valuable customers for $20 million to Akamai and hung the rest out to dry. For context, that’s just 5% of the total funding they’ve received so far.

VC Funded Companies Do Weird Things

The point of all this is to illustrate why you should always be leery of VC funded companies. StackPath needed huge returns to appease their investors. Twenty million buckaroos sounds pretty good to me, but when you’re staring down the barrel of $400 million investor dollars that need to be multiplied, you make extreme choices.

The net result was that we paid the price. Not just us, but every other customer they had. We spent hours of our time investigating and then migrating to a new CDN. Multiply that across all those other customers and you’re looking at thousands of hours wasted, serious operational risks taken, with no real upside for anyone. All because some limited partners wanted their 10x and thought “edge computing” was the buzzword that could deliver it.

Choose Sustainable Companies

When you’re looking for a new vendor, or a new service to use, or a new tool for your stack, you should always factor in the amount of funding a company has taken. What if the investors want them to pivot? What if they need to shut down due to difficult funding conditions? What if you’re a small customer - will they treat you differently because you don’t help their enterprise value or move the needle on their next funding round?

Let’s say you’re in the market for a frontend error monitoring service; there’s plenty of options out there. If you go with TrackJS, you don’t have to worry about that stuff. We’re bootstrapped and profitable. I wrote even more about the importance of profitability, so go read it.

We do frontend error monitoring, and to borrow a famous law firm marketing slogan from my childhood: “It’s all we do, and we do it well”

Postscript

If you’re wondering who we’re using for our CDN services now, it’s bunny.net. They remind us very much of MaxCDN 7 years ago. So far so good. Now we’re just waiting for the AI generated buzzword laden acquisition email.

You have so many options for frontend error monitoring today, and they all do slightly different things. We looked at everyone and did a breakdown of the most important features for frontend, the problems developers run into, end user reviews, and pricing structures to see how the best vendors stack up.

What is Frontend Error Monitoring

Error Monitoring (sometimes called Crash Reporting) is the process of recording errors, exceptions, or problematic events from production software. For most systems, this is done by installing an agent into the software that can listen for errors and send them to a logging service. On the frontend, that means collecting errors from the user’s web browser with JavaScript.

Frontend Error Monitoring is a tricky problem because there is tons of noise coming from robots, malicious users, or unsupported browsers and extensions. On the backend, every error is something real, a failure to be investigated. But on the frontend, we have to sort through the noise to find the real problems.

There are a lot of tools out there that do Frontend Error Monitoring, but very few of them do it well. I am obviously biased in this comparison–I won’t insult you and pretend otherwise. But I think it’s important to highlight the unique challenges of frontend error monitoring specifically, and what you’ll need to be successful.

Key Things to Look For

• Error Telemetry (sometimes called breadcrumbs) are a series of events that lead up to an error, and they are essential to understanding and fixing errors from your frontend. Let’s face it, JavaScript isn’t the best about error handling, and sometimes the messages we get are less than helpful–looking at you Script Error. Telemetry allows us to understand a story about how the user arrived at an error so that we can recreate the situation. TrackJS pioneered Error Telemetry into the industry in 2014.

• Report Filtering is the ability to easily focus the error reports, listings, and charts on only certain attributes. For example, “only show me errors from modern Chrome browsers”, or “don’t include errors that contain ‘facebook’ in the stack trace” are really valuable filtering statements. Having the ability to discover and add this kind of filter allows you to discover the errors that impact your most valuable users.

• Ignore Rules (sometimes called inbound filters) allow you to filter out the noise from the web. Ignore Rules give you the ability to define errors that should never be captured, like from unsupported browsers, parts of the world you don’t serve, or from that noisy third-party that won’t fix their code. Ignore Rules give you control of your data and your costs.

• Pricing Structure varies quite a bit between vendors: some price on seats, others on events, and TrackJS prices on page views. Vendors block different features behind pricing tiers, so be sure to consider the price to get the features you’ll need for your project.

Common Problems

• Too Complicated to Use. With more power comes more complexity. Some tools in the space are really powerful and can do a lot of things–but their UIs tend to turn into spaceship controls along the way. Consider how you will use the tool. If you have an engineer who will be a fulltime monitoring person, then go for the power. If you’ll check it periodically and need to discover answers quickly, a simpler UI might be better for you. Select the tool that you’ll actually use, not the tool you think you need.

• Slow or Unhelpful Support. Integrating software is often challenging. A lot of teams end up with bad tools because they can’t get it installed or working correctly. Make sure that the documentation is helpful and correct, and when you need help, there is someone on the other side who actually knows how things work.

• Unsustainable Vendors. There is nothing more frustrating then getting a bunch of unplanned work because one of your vendors is closing down. Unfortunately, it’s all too common, for companies to get sold off to private equity, and then closed down. When I look at vendors, I tend to pick ones that are profitable and controlled by engineers.

Frontend Error Monitoring Tools

I spend a lot of time researching tools, and how each of these teams is approaching the problem. I tried to normalize pricing for the cost to monitor 1 million errors with the core front features I mentioned above. I also looked at user reviews on G2 to see what people actually think.

Here are the teams that I think are best positioned to solve Frontend Error Monitoring:

Let’s break down each one and cover the strengths and weaknesses, what users think of the product, and about how much it costs.

1. TrackJS

$99

per month

TrackJS is a frontend-only error monitoring platform that tries to solve the signal-to-noise problems on the web by providing discoverable filtering tools and unlimited ignore capabilities. TrackJS launched from Minnesota, USA in 2013 with the innovative Telemetry Timeline that helped developers understand more of their bugs by giving them context into what happened. This feature was so powerful that most other venders have partially implemented it in their own platforms as “breadcrumbs”.

TrackJS has a fixed-tier pricing model that scales on the number of page views rather than error volume. This aligns the goals of TrackJS to reduce the number of customer errors and grow their business (rather than growing when customers have problems).

TrackJS was bootstrapped by the founders and over 10 years later it remains owned and operated by engineers. The tool focuses on simplicity and solving the problems unique to the frontend.

TrackJS Strengths

• Error Telemetry. The original TrackJS Telemetry events captured around user actions and network events contain more detail while preventing any sensitive user information from being recorded automatically.
• Unlimited Ignore Rules. Ignore Rules allow developers to focus on the errors that actually matter. TrackJS allows you to create unlimited rules, as their pricing model does not rely on error volume to be profitable.
• Engineer Owned and Supported. The engineering team is very engaged with customers and support. When you need help, you always get someone who knows how the system works to help you.

TrackJS Weaknesses

• Limited Built-in Integrations. There are few built-in integrations for TrackJS. It only integrates with ChatOps tools like Slack and Teams. Other integrations rely on email or simple API calls that must be built.
• Limited backend platform support. TrackJS is focused on frontend problems, and it’s backend platform support is limited to only NodeJS platforms.

TrackJS Pricing

TrackJS costs only $99 per month to cover 1 million errors (actually up to 2.8 million errors). TrackJS is priced by page views, allowing unlimited errors for that traffic. This Professional plan allows up to 1 million page views. There are no essential features excluded.

TrackJS is rated 4.7/5 on G2.

TrackJS does exactly what you hope it would do. And a lot more of stuff that you didn’t know you needed.

One of the things I like most about TrackJS is the neat reports. The reports they provide are easy to understand and detailed. It is also relatively easy to setup for a beginner! Coming to pricing, it is quite cheaper than the competition.

2. Rollbar

$175

per month

Rollbar started in San Francisco back in 2012 as a tool to capture errors from Ruby applications, but has expanded into many other platforms, including frontend error monitoring. They are funded by VC, and have raised $18.5 million.

Rollbar and TrackJS are the only products in this listing that focus on error monitoring. The allows the Rollbar UI to be clean and simple to use. Rollbar has some powerful machine-learning tools that came in via their acquisition of SameBug that allow errors to be automatically grouped together.

However, Rollbar lacks capability around Ignore Rules and filtering, meaning you’ll have to deal with extra noise from errors that don’t really matter to your users.

Rollbar Strengths

• Multi-Platform. Rollbar supports 10 major platforms, so it’s very likely that you’ll be able to gather backend errors in addition to frontend errors with Rollbar. The integration between them is not as good as Sentry’s though.
• Automatic Grouping. The ML-based error grouping is really quite good in Rollbar. It combines errors that are really referencing the same underlying problem.
• Simple Clean UI. The UI is clean, yet modern. It surfaces the important aspects of errors well.

Rollbar Weaknesses

• Noisy Errors. The lack of Ignore Rule capability is the real problem here. The frontend is definitely not the focus for Rollbar, and you’ll have to deal with a lot of noisy reports and alerts from bots and browser extensions.
• Limited Filtering. The UI filtering is not the best. It relies on a bespoke syntax in a magic search bar that is difficult to understand and use.
• Complex JavaScript Agent. Many users complain about the complexity of integrating the JavaScript agent into their code. The Rollbar agent is one of the largest agents at 80KB, and has a lot of configuration options to review.

Rollbar Pricing

Rollbar costs $175 per month to cover a million errors with required features. Rollbar prices their service per error event, so if you have more bugs you’ll have to pay them more. All essential frontend features are included in the “Essentials” plan.

Rollbar is rated 4.5/5 on G2.

Rollbar gives us centralized error management, error mapping with timelines and usage, great user interface, selection of integrations, and dashboards. Tracking of errors across environments is a huge time saver. Some integrations are more painful than others (looking at you, JavaScript, with your errors and required mapping files) - also error grouping can be difficult to get the hang of

Rollbar captures all the JavaScript errors on our websites. Groups occurrences of the same error together. Good reporting. We have lots of errors that we ignore, it would be nice to categorize these more.

Compare Rollbar vs TrackJS

3. Sentry

$484

per month

Sentry is a fullstack application monitoring platform built for developers to optimize the performance of their code. Sentry works in most platforms and provides a wide range of services including issue tracking, performance monitoring, session replay, code coverage, and everything under the kitchen sink too.

Sentry was launched in San Francisco in 2012 as an offshoot from the Disqus online commenting platform. It is VC funded, having raised $217 million.

Sentry is an incredibly powerful tool, but the lack of focus leads to a lot of complexity in the UI and the documentation. While it can certainly do everything you would need it to do, you’ll likely need a dedicated monitoring engineer to take advantage of it.

Sentry Strengths

• Fullstack Platform. Sentry allows you to trace a frontend error down through the backend services and databases needed to fulfil it. If you are part of a fullstack team, this gives you a lot more breadth in your visibility.
• Integrations with other tools. Sentry has a lot of built in integrations with tools like Jira and GitHub to link you development workflow together.
• Open Source Model. (Kinda). Most of Sentry is Open Source, so you can see exactly how it works or run it yourself on your own hardware.

Sentry Weaknesses

• Fullstack Platform. Wait, isn’t that a strength? It’s both. Because Sentry needs to support so many different ideas, the UI is somewhat unfocused and complicated. They don’t have good filtering and grouping concepts, which are critically important for the frontend, but not at all useful for the backend.
• Complex UI and Documentation. Many users remark how the Sentry UI is complicated to use from all the different things it does. This same complication is visible in their documentation. The learning curve to use Sentry effectively is high.
• High Cost for Required Features. Some of the most important features, like Server Side Filtering, is locked behind the high-cost “Business” tier.

Sentry Pricing

Sentry pricing is complicated with mutliple meters. To cover 1 million errors with required features costs a whopping $484 per month. Sentry is priced per error event–the more errors you have, the more you have to pay. Important frontend features like “server-side filtering” (AKA Ignore Rules) are limited to the Business plan.

Sentry is rated 4.5/5 on G2.

Sentry is Helpful in monitoring and notification when we have failures in Production / non-Production environments. Very difficult to filter the error.

Sentry gives us detailed information, integration with Jira, can check the exact error in code, but complicated to use.

Compare Sentry vs TrackJS

4. Raygun

$600

per month

Raygun is a application monitoring platform from New Zealand that’s been around since 2007. It was developed as a product from Mindscape, a .NET developer tooling company, but has expanded into more platforms including the frontend web monitoring space. Raygun provides Crash Monitoring, Application Performance Monitoring, and Real User Monitoring.

Raygun offers a wide variety of services to developers, especially in the .NET stack where you can leverage licensing across other tools in their portfolio.

I think one of the most powerful features of Raygun for frontend error monitoring is their error grouping capability, which allows you to normalize errors between languages and browsers easily.

Raygun Strengths

• Error Grouping. Raygun has some cool advanced capabilities around custom error groupings that allows things that appear different to be reported together. This can be very powerful for complex and diverse applications.
• Performance Monitoring. Raygun does performance monitoring alongside it’s error monitoring product (at additional cost). While not strictly beneficial to fixing errors, errors are sometimes the cause of performance degradations.
• Advanced Alert Builder. Raygun allows you to build custom alerting rules with all kinds of knobs and options to make it whatever you want. This can be a double-edged sword though, as teams will often over-alert themselves.

Raygun Weaknesses

• High Costs. Despite it’s features, Raygun is the most expensive option in this comparison just for the error monitoring components. The other benefits would need to be a good fit for your organization to be worth the price tag.
• Complicated Ignore Rules. While Raygun does have ignore rules, they are difficult to use correctly, and have a high cost from irrelevant errors if you get them wrong.
• Filters are Hard to Use. Filtering reports in Raygun is difficult to discover, using a bespoke syntax with no result hints.

Raygun Pricing

Raygun is the most expensive option on this listing, costing $600 per month. Raygun is priced per error event–the more bugs you have, the more you have to pay. The “Team” plan is required to have ignore rules (inbound filters), and you need to account for additional volume to cover 1 million errors.

Raygun is rated 4.3/5 on G2.

Raygun gives us the ability to match errors in the crash reporter with users and create issues directly from those. Helpful for developers and support alike. The filter system is a bit janky.

Raygun has clean and configurable dashboard and constantly being developed. The most significant disadvantages of Raygun was the way that unpredicted error spikes were handled. Meaning they could eat up all capacity for entire month.

Compare Raygun vs TrackJS

5. BugSnag

$549

per month

BugSnag started in San Francisco in 2012 as a fullstack error monitoring platform, which was very unique at the time. Their product has expanded into the full Application Performance Monitoring space, going after more enterprise customers.

BugSnag was funded by venture capital and acquired by Private Equity holding SmartBear in 2021. Since then, their prices have increased substantially.

BugSnag Strengths

• Multi-Platform. BugSnag supports lots of different platforms, allowing you to align your frontend and backend processes, or grouping your mobile and web data together.
• Responsibility Segmentation. BugSnag allows you to segment complex systems into different team responsibilities.
• Discarding Errors. BugSnag allows you to create “Ignore Rules” for errors in what they call discarding. However, they only allow this by browser or app version, so it is pretty limited.

BugSnag Weaknesses

• High Costs. BugSnag is one of the highest priced options in this listing, bug misses a few important capabilities.
• Private Equity. Since being purchased by Private Equity, costs have risen significantly, and development has slowed. I would be concerned about the sustainability of this product.
• Complicated Setup and Documentation. Users complain about complicated onboarding, setup, and integration. Their documentation is difficult to navigate.

BugSnag Pricing

BugSnag prices by seat and error volume, so you need to check the number of people on your dev team in addition to expected error volumes. With the base number of users, it already costs over $580 per month. The “Standard” plan includes all required features, and includes up to 1.5 million events.

BugSnag is rated 4.3/5 on G2.

BugSnag is easy to integrate once you get the configuration correct. And the web site for monitoring/reviewing exceptions is fantastic. Getting the configuration correct in some cases was not easy.

BugSnag is very simple to set up and maintain; it has powerful search capabilities and workflow mechanisms, with lots of additions information required. The API can be a little cumbersome and the documentation isn’t awesome at times.

Compare BugSnag vs TrackJS

Lots of Other Vendors

There are lots of other vendors in the error monitoring space. It’s the kind of problem that every developer wants to fix, so I see a new service startup every month or so.

Most of them are copy-cats of one of the services above with a slightly different UI. Based on what I found in Wappalyzer and BuiltWith, none of them have significant traction, and I’d be concerned about their ability to scale and support customers.

Conclusions

You have a lot of options when it comes to error monitoring for frontend applications. The right choice will depend on your software, your team, and your preferences for risk.

Do you need to manage frontend and backend systems? Rollbar might be a great choice. Do you want to add lots of extra tools to your toolbelt, and you have the budget to do it? Check out Sentry.

If you need to understand your frontend though, and really cut through the noise to see the errors that really matter, TrackJS is the best rated, cheapest, and most feature-rich option for you.

I know, I was shocked that that conclusion as well 😉. The best way to decide is by seeing your own errors though, so get started with a free trial and see if TrackJS works for you.

A few days ago a memo from logistics company Flexport leaked to the media announcing significant layoffs. Now, a tech company doing layoffs in 2023 is hardly notable. A 20% RIF here and there is almost expected. What is notable is the reason for the layoffs: Flexport is trying to achieve profitability.

Why Profitability Matters

In the leaked letter, Flexport CEO Ryan Petersen says the following:

I’ve spoken to more than 100 of our top customers in my first month back as CEO, and … it’s clear that our customers want us to be a profitable company they can rely on to solve important problems in their supply chain.

So their customers (and presumably prospective customers) are demanding profitability! My how the times are changing.

When you’re looking for a vendor to help manage your supply chain, you want a company with staying power. One who’ll be around in a decade, or two, or three. Changing vendors is always time consuming, expensive and risky. And here Flexport’s customers are telling it: you need to show us you’ll be here in ten years or we don’t feel comfortable doing long-term business with you!

There’s no better signal of company health and longevity than being consistently profitable. That is - making more money than you spend. Not some Wall St. non-GAAP version of profitable mind you, but actual positive net income.

But wait - if Flexport isn’t profitable now, how have they been operating and paying their 3,200 employees these past 10 years?

Straight VC Cash, Homie

According to Crunchbase, Flexport has raised a staggering $2.4 billion in investor funding over 18 rounds of financing. For ten years they’ve paid their employees not with revenue from operations, but from a horde of VC cash.

The CEO even alludes to it in his letter:

With more than $1 billion in net cash, following this change, Flexport is now in a great position to take advantage of the opportunities in front of us to return to profitability as soon as the end of next year.

So they’re still sitting on over $1 billion in cash. What’s particularly notable is that they’ve already burned more than $1.4 billion of their money pile! And the money fire won’t die down enough for profitability until the end of next year.

The Dangers of Free Money

One downside of heaps of VC cash is unsustainable business models don’t fail early. Companies who shouldn’t exist are given millions (or sometimes billions - looking at you Softbank) to prop up bad products or services. This is sometimes called malinvestment.

When interest rates were low and lots of capital was looking for returns - money was sloshing everywhere, even to garbage companies with silly business models (ahem, scooters). Instead of that money helping solid businesses grow sustainably, it distorted markets and led to situations where inefficient or bad businesses crowded their way in and destroyed or prevented otherwise sustainable ones from succeeding.

This trend is so pervasive in VC, that in 2019:

Sixty-four percent of the 100+ companies valued at more than $1 billion to complete a VC-backed IPO since 2010 were unprofitable, and in 2018, money-losing startups actually fared better on the stock exchange than money-earning businesses.

Times Are Changing

Fortunately with the move away from near-zero interest rate environments, the VCs appear more circumspect now. I’ve heard it’s a tough fundraising environment and not the torrential rainstorm of free money it was. The stock market might finally start to care about profitability too.

Behold Splunk!

Here is a company, who incredibly, for it’s 10+ years of existence, never once had positive net income! Shit, they had negative shareholder value for year-end 2023. This means their liabilities exceeded their assets and shareholders were (on paper) underwater. To bathe in the public’s largesse for so long and still pretend to be a sustainable business! Well the music stopped and Splunk couldn’t find a chair.

Yeah, I know the press release made it sound real good - Cisco and Splunk, think of the synergies! Well how about these synergies:

Expected to be cash flow positive and gross margin accretive in first fiscal year post close, and non-GAAP EPS accretive in year 2

That’s a fancy way of saying Splunk ain’t gonna help with profitability. “Non-GAAP EPS accretive in year 2” - words only an M&A lawyer could love.

So anyways, now they’re owned by Cisco [ominous laughter]. If you’re a Splunk customer, I assume you’re already used to the ankle-grabbing prices but just imagine what Cisco is going to do to those enterprise agreements! Add a couple of zeroes to those invoices, that’s one thing they’re gonna do.

Selling Dollars for Dimes

Unprofitable companies like Splunk are a risk. They might go out of business. They might change, remove or destory their product offerings in order to make more money. They might raise prices massively when things get tough. They might even get bought by a stagnant “tech” company who’s best days are far behind it and exists only to extract the last ounce of revenue from enterprise customers.

So, when looking at a vendor for anything - be it logistics or JavaScript error monitoring - you should look for profitable companies first!

TrackJS is Profitable!

See, there was a point to this whole post! TrackJS has been profitable for years! Coming up on a decade now, in fact. We’ve done it by keeping infrastructure costs low (more on that in another post) and keeping our scope reasonable.

We don’t want to be the everything platform - we don’t need hundreds of employees. We make simple tools that solve real customer problems. And we’ll be here for the next ten years.

We’re Bootstrapped Too

Profitability isn’t our only trick, either. We’re also bootstrapped! There is no outside investor looking for big returns. There’s no one with our feet to the fire to hit unrealistic growth targets for the sake of their already-rich LPs.

Not a Patagonia vest in sight.

It’s just the people who work here, making solid salaries and building the best JavaScript error monitoring tool there is.

Alerts and notifications have been part of TrackJS since the very beginning. Our standard notification options reflect our desire to keep things simple. Over time though, our customers have asked to customize their alerts and fine tune them to specific scenarios. To support that use case, we’re releasing a new kind of notification we’re calling “Saved Filter Notifications”.

New Filter Based Alerting

Some customers use TrackJS as an early warning system - if an error with a specific message shows up, it means big trouble and they want to know about it right away. Other customers want to know if their APIs are acting flaky. And some want to know if their most important users are having trouble.

There’s dozens of reasons you might want to know when certain errors show up (or start happening more frequently). To that end we’ve recently launched a new filter based notification system. Now you can tell us which errors you care about, and we can tell you when they start happening!

Saving a Filter

To make use of the new custom notifications, the first thing you need to do is create a filter for the errors you care about. You can filter based on error message, entry type, URL, user and myriad other facets. It’s easy - just click on the global filter bar at the top of the screen and make your selections.

After you’ve filtered to the relevant errors, click the “share” dropdown in the upper right hand corner of the UI. A menu will appear and you can enter a name for your filter. Click the Save button.

Configuring Alerts for a Saved Filter

Once saved, you can click the Manage Alerts link from the same “share” dropdown. You’ll see a list of all your saved filters, and any pre-existing notification channels.

Find the saved filter you want to configure alerts for and click the “+ Add Notification” link.

Customizing Notifications

The new saved filter notifications work using four different strategies (more on that below). Those strategies are based on a Lookback Period and an Error Threshold.

The Lookback Period is how large of a time window to use when considering a filter’s error volume. The Error Threshold is the minimum number of errors that must occur during the lookback period before an alert is sent.

For example, if a filter has a high base level of errors, it might make sense to set the error threshold high, and a short lookback window. This way you’ll need a decent spike in a short period of time to cause an alert.

On the other hand, if there’s a situation where you want an alert any time an error matches a filter - a longer window with a lower threshold will make the alert more sensitive.

And, like our other notifications, you can notify as many channels at a time as you’d like.

How it Works

We use four different strategies when determining whether to alert. Each strategy will decide to trigger or not based on the filter’s error volume over time. Two of the strategies must be triggered in order for a notification to be sent (this cuts down on noise and false positives). We use the following strategies:

• Simple Historical Average: This simple strategy compares the filter’s historical average error volume to the lookback period’s current volume and, if the current volume exceeds a multiple, triggers.
• Standard Deviation: This strategy triggers if a filter’s current error volume is multiple standard deviations higher than the historical volume.
• Moving Average: If the moving average of the error volume in the lookback period is several multiples higher than the historical volume, the strategy is triggered.
• ML Detection Strategy: An ML prediction strategy which finds spikes in time series data based on adaptive kernel density estimations and martingale scores. If the confidence is over 99.9% the strategy triggers.

Conclusion

With the new saved filter based notifications, customers can pick and choose when and why they’re alerted. Filters can be broad, and capture many errors - or very granular and only trigger in rare conditions. No matter your use case, it’s likely that a well chosen filter with proper alert settings will ensure you’re notified when anything goes wrong.

We’re always on the lookout for new ways to improve customer experience, so if you’ve got suggestions please let us know!

As JavaScript has grown more prevalent on the web, so have JavaScript errors. As an error monitoring service, we have a unique perspective on how errors impact the web globally, and we are constantly learning more about how the web breaks. We’re thrilled to share this report today so we can all understand it better, and build a better web.

We produce this report every week, you can check it out anytime via the free Global Error Statistics report.

Error Volume by Browser

The browser JavaScript runtime is an important part of the client-side error story. Error volume is a function of both the popularity of the browser, as well as how likely it is to produce errors.

The browser market leaders of Chrome, Firefox, and Internet Explorer 11 represent a majority of the browser market today, so it follows they report a large portion of errors.

Mobile Safari and older Internet Explorer begin representing the friction building web applications for those platforms. Mobile Safari has challenges debugging, as does the infamous developer tools available for IE8 and 9. While much of the web is pushing forward with new APIs and capabilities, many of us are still fighting the old compatibility problems.

Error Volume by Application Framework

A majority of client-side JavaScript applications use a framework of some kind to assist in the architecture and structure of the system. Error volume by Framework is a reflection of both popularity of the framework and the patterns exercised its community.

Angular represents the majority of both usage and errors today, however it seems to create a disproportional amount of errors compared to other frameworks. On the opposite of the spectrum, smaller tools like React and Knockout seem to experience relative low error volumes in our sample.

Top 5 JavaScript Errors

By Number of Applications Affected

The “Big Five”, these specific errors are the most common, measured by the number of unique web applications impacted:

1. Script Error

The arch nemesis of JavaScript error monitoring, we’ve covered Script Error in depth with our JavaScript Forensics series. Script Error stems from browsers implementing the Same-Origin Policy on your scripts and obfuscating error details.

2. Error Loading Script

This error is emitted from the very popular requireJS library when a script fails to loaded asynchronously. Scripts can fail for many reasons, and it’s always a good practice to check for the existence for the SDK provided by a library before referencing it.

3. Undefined is not a function

The incredibly common reference error, which we have all encountered many times. This is likely due to loss of context when invoking a callback. Our friend Kyle has the best explanation of this problem around.

4. Cannot read property ‘length’ of undefined

You think it’s an array or a string? It’s not. It’s undefined. This all-too-common message results from referencing elements or objects that do not exist. Here’s a full rundown on the error from our JavaScript Error knowledge base.

5. Object doesn’t support this property or method

We don’t know what object, we don’t know what it is, and we don’t know what it’s named, but it broke. This infuriating error reinforces the ongoing frustration debugging Internet Explorer 8. Calling a restricted function, or accessing an unimplemented property can result in a catastrophic error.

Error Rollup Score

Overall, we can roll-up a score for JavaScript quality today, comparing total sampled page-views with errors. It doesn’t paint a rosy picture.

39% of page views will experience a JavaScript error. That’s a lot of shopping carts abandoned, searches failed, and customers unhappy.

JavaScript on the web is error prone, but it can get better. Let us help make your web applications better with a free trial of TrackJS. We’ll let you know when your customers have problems with the context to recreate and fix bugs