Cutting error tracking costs

Error tracking is billed by the number of $exception events you capture. The price per event changes based on your usage. You can estimate your costs using our pricing calculator below, and click see how we calculate this to understand the exact breakdown:

We aim to be significantly cheaper than our competitors. In addition to our pay-as-you-go pricing, below are tips to reduce your error tracking costs.

What contributes to your bill?

Error tracking bills you based on the number of $exception events ingested by PostHog each month. This means if you send exception events to PostHog, they will be billed.

This also means:

• The total number of exceptions stored in PostHog does not contribute to your bill.
• The number of issues in PostHog does not affect your bill, only the individual exception events that make up the issues.
• Merging, resolving, and suppressing issues in PostHog does not reduce your bill.

Preventing surprise bills

Like all PostHog products, you can set a billing limit for error tracking. When a project exceeds this limit, PostHog will no longer capture exception events until your billing period resets.

Tips to reduce your bill

The best way to reduce your bill is to reduce the number of $exception events you send to PostHog from the client-side. This means being more selective about which exceptions are captured.

Configure exception autocapture

By default, we capture all unhandled errors and rejections. This can capture more than you need. To reduce which exceptions that are captured, you can configure which types of exceptions are autocaptured in the JS SDK config like this:

{
  "capture_exceptions": {
    "capture_unhandled_errors": true,
    "capture_unhandled_rejections": true,
    "capture_console_errors": false
  }
}

Alternatively, you can disable exception autocapture completely in your project settings.

Suppression rules

Autocaptured exceptions can be ignored client-side by configuring suppression rules in PostHog settings. You can only filter based on the exception type and message attributes because the stack of an exception may still be minified client-side.

Burst protection

The JavaScript web SDK uses burst protection to limit the number of autocaptured exceptions that can be captured in a period. This prevents an excessive amount of exceptions being captured from any one client, typically because they're being thrown in an infinite loop.

By default, we capture 10 exceptions (bucket size) of the same type within a 10 second period before the rate limiter kicks in, after which, we capture 1 exception (refill rate) every 10 seconds.

Often not needed, but you can change the bucket size and refill rate as part of your configuration:

import posthog from 'posthog-js'

posthog.init('<ph_project_api_key>', {
    api_host: 'https://us.i.posthog.com', 
    error_tracking: {
        __exceptionRateLimiterRefillRate: 1
        __exceptionRateLimiterBucketSize: 10
    }
})

Using the before_send hook

You can use the before_send callback in the web and Node.js SDKs to exclude any exception events you do not wish to capture. Do this by providing a before_send function when initializing PostHog and have it return a falsey value for any events you want to drop.

posthog.init('<ph_project_api_key>', {
    before_send: (event) => {
        if (event.event === "$exception") {
            const exceptionList = event.properties["$exception_list"] || []
            const exception = exceptionList.length > 0 ? exceptionList[0] : null;

            if (exception && exception["$exception_type"] === "UnwantedError") {
                return false
            }
        }
        return event
    }
})