A recovery checkpoint is an atomically updated file that preserves everything a Bulk Run needs to resume — the unresolved rows, the run settings, each row’s attempts and states, and the paths to artifacts already written — so an interrupted run can pick up where it stopped instead of starting over.
| Term | Recovery Checkpoint |
|---|---|
| Category | APIs, Reliability and Publishing |
| Also known as | Durable Recovery File |
| Where it appears | Bulk Runs |
What it means in RankGear
When you launch a Bulk Run — a queue of rows that each call providers, fetch pages, or publish output — RankGear maintains a recovery checkpoint alongside it. The file is rewritten atomically: RankGear writes the new state to a temporary path and swaps it into place in a single operation, so a crash partway through a write can never leave a half-updated, corrupt checkpoint. If the app closes, the machine reboots, or the run is cancelled, reopening the run reads the checkpoint and rebuilds the queue from it. Rows that already finished stay finished, in-flight rows return to their last recorded state, and artifact paths point at work that was already saved rather than triggering it again.
How to interpret it
Treat the checkpoint as the source of truth for what still needs doing, not as a running log. When you resume, read each unresolved row’s visible status and diagnostics before retrying it, because the checkpoint stores enough to tell a transient failure apart from broken configuration. A timed-out fetch or a rate-limit response is transient and worth one bounded further attempt; an authorization error or a 404 is a configuration problem that retrying will not fix. Because attempt counts are recorded per row, a row that has already exhausted its retries is not silently hammered again on resume.
| What the checkpoint preserves | Why it matters on resume |
|---|---|
| Unresolved rows | Finished work is not repeated; only the remaining queue is replayed. |
| Run settings | A resumed run behaves identically to the original, not a re-guessed configuration. |
| Attempts and states | Retry decisions stay bounded, using each row’s count and last known status. |
| Artifact paths | Outputs already written are reused instead of regenerated. |
Example
A 400-row Bulk Run that publishes rewritten pages to a remote WordPress site loses its connection at row 260 when the laptop sleeps. On resume, the checkpoint shows 259 rows done with their published URLs recorded, one row that was mid-publish returned to a pending state, and 140 rows still untouched. RankGear re-runs only the single interrupted row and continues from row 261 — no duplicate posts, and no repaid provider calls for the 259 already complete.
Important considerations
- A checkpoint records state; it does not guarantee success. Resuming replays unresolved work, but a row that failed for a configuration reason will keep failing until the underlying credential or target is corrected.
- Credentials and remote publishing targets need care. Where possible, connection tests should be read-only, so a diagnostic check confirms access without mutating a live site.
- Secrets stay redacted. The file holds what a run needs to resume, but API keys and passwords are kept out of it or masked, so a recoverable artifact never becomes a credential leak.
- Retries are bounded because paid provider calls cost money. An authorization failure stops the row rather than retrying it repeatedly against the provider.
Related terms
Part of the RankGear glossary · how RankGear measures · the 870 factors.