---
title: Store and forward
slug: how-tos/ignition-module-store-and-forward
docTags: iDPLS9QxpsGnuNftqI_r1
createdAt: 2026-09-18T08:00:00.000Z
---

Each historian profile gets its own Ignition Store & Forward engine, created automatically and named after the profile. When Factry Historian or the network is unavailable, points queue in the pending buffer and are forwarded once the connection returns. No configuration is required to get this behavior.

The module detects an outage on the first failed write, so the points that follow go straight to the buffer instead of waiting on a timeout. It also moves quarantined records back to pending every 30 seconds, because failures here are almost always transient connection problems rather than bad records. Ignition never retries quarantined data by itself.

## Monitoring

Both the engine settings and its buffered records live on **Platform > System > Store and Forward** in the Ignition Gateway:

- **Pending count**: records waiting to be forwarded. During an outage this should climb steadily.
- **Quarantined count**: records that failed forwarding. This should stay near zero.

A pending count stuck at zero while tags are changing means points are being lost before they reach Store & Forward. Check the gateway logs.

After the connection is restored, the module can take up to 30 seconds to notice before forwarding resumes.

## Recommended settings

Tune the engine on the same page. For typical deployments:

| Setting                           | Suggested     | Why                                                                                                                                              |
| --------------------------------- | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ |
| Forward rate                      | 1000 ms       | Balance between write latency and load on the Historian.                                                                                         |
| Time threshold                    | 5000 ms       | Flush to the disk cache quickly, so a gateway crash loses little.                                                                                |
| Data threshold                    | 1000 records  | Flush before the memory buffer grows large.                                                                                                      |
| Primary store maintenance value   | 0 (unlimited) | The default, and worth leaving alone. When a limit is reached the default action is `PREVENT_NEW_DATA`, which drops points during a long outage. |
| Secondary store maintenance value | 0 (unlimited) | Same, for the disk cache.                                                                                                                        |