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

# Exposure Calculation Stuck

> When exposure calculations never complete and remain stuck in Waiting status

## Symptoms

You're experiencing this if:

* Apply events exist in your assignment table
* The status for your exposure calculation in the **Exposure** section on the right sidebar of the result page shows "Waiting" status
* The time the calculation is waiting for is far in the past (hover the calculation status to see the time)

The calculation **hasn't run yet** because it's waiting for data to settle. A completed calculation finding zero exposures is a different issue.

***

## Common Causes & Solutions

### Cause 1: Assignment Table Commit Threshold Blocking

#### Symptoms

* Applies arriving continuously in your assignment table
* Exposure calculation perpetually waiting
* More common with mobile apps or offline users (where apply events arrive in batches)

#### Explanation

Confidence waits for apply events to "settle" before calculating exposure. It uses a **commit threshold** to determine when a partition is ready. The exact configuration varies depending on the data delivery cadence of your assignment table to find when a partition is ready. The most common scenario:

* Monitors row count changes in 5-minute windows
* When change ≤ threshold %, commits partition and calculates exposures
* **Default threshold: 0%** (waits for completely zero new rows)
* If applies keep trickling in, partition never commits

**Example scenario:**

```text theme={null}
We want to calculate exposures for the 10:00-11:00 hour partition.

11:05 (5-min delay): Check for new applies with timestamps 10:00-11:00
  - Found 20 new applies that arrived between 11:00-11:05
  - Partition still changing, don't commit yet

11:10: Check again for timestamps 10:00-11:00
  - Found 10 more applies that arrived between 11:05-11:10
  - Still changing, don't commit

11:15: Check again for timestamps 10:00-11:00
  - Found 5 more applies that arrived between 11:10-11:15
  - Still changing, don't commit
```

This continues indefinitely as offline users keep coming online and
sending cached applies with timestamps in the 10:00-11:00 range. The commit threshold is not met because the change is greater than the commit threshold.

**Common scenarios:**

* Mobile apps with offline functionality
* Apps in areas with poor connectivity
* Games with offline modes
* Apps that batch/cache events

#### Diagnosis

<Steps>
  <Step title="Check assignment table commit threshold">
    1. Go to the Design tab of your experiment
    2. Select the assignment table in the **Metric config** section on the right sidebar
    3. Check **Commit threshold** setting
    4. Check **Commit delay** setting
  </Step>

  <Step title="Check commit logs">
    1. Navigate to your experiment's result page
    2. Select the status field for any of the metric calculations in the **Metric calculations** section on the right sidebar
    3. Expand the **Exposure** section at the top

    The **Timestamp** column shows when Confidence checked for new applies, and the **Partition** column for which time partition. The log describes the result of the check. Example logs:

    1. `Found 820 rows, waiting for data to stabilize.` The first check that obtains the initial count of applies in the partition.
    2. `Found 830 rows, previously had 820 rows, waiting for data to stabilize.` The second check that detects a change in the count of applies and waits for the count to stabilize.
    3. `Committed 830 rows, moved forward time to 2025-11-11T11:00Z.` The third check that commits the partition and moves forward the time to the next partition.
  </Step>
</Steps>

#### Solution

If you want to tolerate more changes in the count of applies, you can adjust the commit threshold to a higher value. This allows Confidence to commit the partition sooner, but it also means Confidence excludes some assignments from the exposure calculations.

### Cause 2: Commit Delay Too Long

#### Symptoms

* Applies stopped arriving days ago
* Exposure still waiting

#### Diagnosis

Check commit delay setting:

1. Go to the Design tab of your experiment
2. Select the assignment table in the **Metric config** section on the right sidebar
3. Check **Commit delay** setting

**Example problem:**

```text theme={null}
Last apply: January 15
Commit delay: 7 days
Today: January 18
```

#### Solution

Reduce commit delay to a shorter period, like 5 minutes or 1 hour.

## Related Resources

<CardGroup cols={2}>
  <Card title="Assignment Tables" href="/docs/capabilities/metrics/assignment-tables">
    Configure assignment tables
  </Card>

  <Card title="Exposure Reference" href="/docs/capabilities/metrics/exposure">
    Understand exposure calculations
  </Card>

  <Card title="Metric Data Errors" href="/docs/troubleshooting/experiments/metric-data-errors">
    Troubleshoot metric data issues
  </Card>

  <Card title="Analyze Results" href="/docs/capabilities/experiments/analyze-results">
    Understand experiment results
  </Card>
</CardGroup>