> ## Documentation Index
> Fetch the complete documentation index at: https://docs.apsio.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Sampling

> Keep the detail of a share of sessions while crashes, errors and release health stay complete.

Sampling lowers how much an app sends without losing crashes or release health. A session
whose detail is kept is a captured session, the unit of [pricing](/pricing).

## What is sampled

The decision is made once per session, when it starts, so a session is kept or dropped
whole.

| Always sent, from every session | Sent only from kept sessions |
| - | - |
| Session start, end and summary | Spans: app start, screen loads, network requests, your own spans |
| Crashes, terminations without a crash report and hangs | Logs below Error |
| Handled errors and logs at Error or above | |
| MetricKit reports | |

Crash-free rates, session counts and users are therefore exact at any rate. See
[release health](/concepts/sessions#release-health).

## Setting the rate

The rate is part of the app's [remote configuration](/remote-configuration): 100% by default.
A change applies to sessions that start after the device receives it, with no app release.

## How the decision is made

The decision is a hash of the session id: the session is kept when the first 8 bytes of
SHA-256 of the id, read as a number, are below the rate times 2⁶⁴. Any SDK or server
computes the same answer for the same session. Records from kept sessions carry the
rate (`apsio.sampling.session.rate`), so counts built from detail can be scaled back up.

The exact rule is in the [specification](https://spec.apsio.io/v0.1/).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.