---
title: "Sampling"
description: "Learn how to configure the volume of error and transaction events sent to Sentry."
url: https://docs.sentry.io/platforms/javascript/guides/electron/sampling/
---

# Sampling | Sentry for Electron

Adding Sentry to your app gives you a great deal of very valuable information about errors and performance you wouldn't otherwise get. And lots of information is good -- as long as it's the right information, at a reasonable volume.

## [Sampling Error Events](https://docs.sentry.io/platforms/javascript/guides/electron/sampling.md#sampling-error-events)

To send a representative sample of your errors to Sentry, set the `sampleRate` option in your SDK configuration to a number between `0` (0% of errors sent) and `1` (100% of errors sent). This is a static rate, which will apply equally to all errors. For example, to sample 25% of your errors:

```javascript
Sentry.init({ sampleRate: 0.25 });
```

The error sample rate defaults to `1`, meaning all errors are sent to Sentry.

Changing the error sample rate requires re-deployment. In addition, setting an SDK sample rate limits visibility into the source of events. Setting a rate limit for your project (which only drops events when volume is high) may better suit your needs.

## [Inheritance](https://docs.sentry.io/platforms/javascript/guides/electron/sampling.md#inheritance)

Whatever a transaction's sampling decision, that decision will be passed to its child spans and from there to any transactions they subsequently cause in other services.

(See [Distributed Tracing](https://docs.sentry.io/platforms/javascript/guides/electron/tracing/trace-propagation.md) for more about how that propagation is done.)

If the transaction currently being created is one of those subsequent transactions (in other words, if it has a parent transaction), the upstream (parent) sampling decision will be included in the sampling context data. Your `tracesSampler` can use this information to choose whether to inherit that decision. In most cases, inheritance is the right choice, to avoid breaking distributed traces. A broken trace will not include all your services.

```javascript
tracesSampler: samplingContext => {
  // always inherit
  if (samplingContext.parentSampled !== undefined) {
    return samplingContext.parentSampled
  }

  ...
  // rest of sampling logic here
}
```

If you're using a `tracesSampleRate` rather than a `tracesSampler`, the decision will always be inherited.

## [Precedence](https://docs.sentry.io/platforms/javascript/guides/electron/sampling.md#precedence)

There are multiple ways for a transaction to end up with a sampling decision.

* Random sampling according to a static sample rate set in `tracesSampleRate`
* Random sampling according to a sample function rate returned by `tracesSampler`
* Absolute decision (100% chance or 0% chance) returned by `tracesSampler`
* If the transaction has a parent, inheriting its parent's sampling decision
* Absolute decision passed to `startTransaction`

When there's the potential for more than one of these to come into play, the following precedence rules apply:

1. If `tracesSampler` is defined, its decision will be used. It can choose to keep or ignore any parent sampling decision, use the sampling context data to make its own decision, or choose a sample rate for the transaction. We advise against overriding the parent sampling decision because it will break distributed traces)
2. If `tracesSampler` is not defined, but there's a parent sampling decision, the parent sampling decision will be used.
3. If `tracesSampler` is not defined and there's no parent sampling decision, `tracesSampleRate` will be used.