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

# Runtime

> runtime

ReferenceApplies to: Unified engine deployments

`[runtime]`

## Background work

### `background_interval`

Sets how often background services check for pending work.

* **Default:** `1 s`
* **Type:** duration

> **Example**
>
> `{ secs = 1, nanos = 0 }` runs the next background check about one second later. It is not a workload schedule.

## Retry policy

### `retry.strategy`

Chooses how the wait between retries grows.

* **Default:** `Exponential`
* **Type:** choice: `Constant`, `Exponential`, `Fibonacci`

> **Example**
>
> Exponential backoff can wait 100 ms, then 200 ms, then 400 ms, until its configured maximum delay. Configure one strategy at a time.

### `retry.strategy.Constant.delay`

Sets the fixed wait between retries for the Constant strategy.

* **Default:** Set when used
* **Type:** duration

> **Example**
>
> `{ secs = 1, nanos = 0 }` waits one second each time rather than increasing the delay.

### `retry.strategy.Exponential.min_delay`

Sets the shortest wait used by this retry strategy.

* **Default:** `100 ms`
* **Type:** duration

> **Example**
>
> A 100 ms minimum lets the first retry happen quickly, while later retries can wait longer according to the selected strategy.

### `retry.strategy.Exponential.max_delay`

Caps how long the retry strategy waits between attempts.

* **Default:** `5 s`
* **Type:** duration

> **Example**
>
> A five-second maximum stops backoff from growing beyond five seconds between retries.

### `retry.strategy.Exponential.factor`

Sets how much an Exponential retry delay grows after each retry.

* **Default:** `2.0`
* **Type:** number

> **Example**
>
> A factor of `2.0` can grow a 100 ms delay to 200 ms, then 400 ms, until max\_delay is reached.

### `retry.strategy.Fibonacci.min_delay`

Sets the shortest wait used by this retry strategy.

* **Default:** Set when used
* **Type:** duration

> **Example**
>
> A 100 ms minimum lets the first retry happen quickly, while later retries can wait longer according to the selected strategy.

### `retry.strategy.Fibonacci.max_delay`

Caps how long the retry strategy waits between attempts.

* **Default:** Set when used
* **Type:** duration

> **Example**
>
> A five-second maximum stops backoff from growing beyond five seconds between retries.

### `retry.max_retries`

Limits the number of retries allowed by the shared retry policy.

* **Default:** `3`
* **Type:** integer

> **Example**
>
> `3` bounds the retries after an operation asks to be retried. It does not bypass checks for whether a write already succeeded.

### `retry.jitter_seed`

Optionally makes the random variation in retry timing repeatable.

* **Default:** Unset
* **Type:** integer; optional

> **Example**
>
> A fixed seed is useful when reproducing a test. Leave it unset when you do not need the same sequence of retry delays.

## Retry strategies

`runtime.retry.strategy.Constant` uses one `delay`. Exponential grows between `min_delay` and `max_delay` using `factor`. Fibonacci grows between the same bounds using its sequence. Keep only one strategy in a file. Retrying an operation does not bypass commit confirmation.


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