A persistent job is a unit of work the engine owns and keeps running while you move around the app — an analysis, a publishing run, or any coordinated task carries on in the background, and its progress and results return to the screen that started it.
| Term | Persistent Job |
|---|---|
| Category | APIs, Reliability and Publishing |
| Also known as | Engine-Owned Job |
| Where it appears | Analysis, publishing, and software-wide work coordination |
What it means in RankGear
Persistent jobs are how RankGear keeps long-running work alive independently of the screen you happen to be looking at. When you launch an analysis, start a publishing run, or trigger any coordinated task, the engine — not the view — takes ownership of it. You can navigate to another section, open a saved report, or adjust settings while the job keeps advancing. When it completes, its status and output are routed back to the originating screen so you resume where you left off. Because the engine owns the job rather than the UI, closing or reloading a single view does not discard the work in progress.
How to interpret it
Read a persistent job through its visible status, diagnostics, retry decision, and any credential test rather than assuming that a stalled item has failed outright. Those signals separate a transient problem — a page that timed out, a momentary provider hiccup — from a configuration problem, such as an invalid key or a wrong publishing target. A transient failure is a reasonable candidate for a single bounded retry; a configuration failure is not, and repeating it only burns paid calls. Use the diagnostics to decide which case you are in before you act.
| What you see | What it tells you |
|---|---|
| Timeout or momentary provider error | Likely transient — a bounded retry may clear it. |
| Authorization or invalid-target error | Configuration problem — fix credentials or target; do not retry blindly. |
| Steady progress or completion status | Job is healthy; results will return to the originating screen. |
Example
Say you start a publishing run to a remote WordPress target and switch to the Analysis screen to review a report while it works. One page’s request times out, so the engine grants it a single bounded longer retry and it succeeds. Another page comes back with an authorization error; instead of hammering the endpoint with repeated paid calls, the engine stops that leg and surfaces the credential failure in diagnostics. When you return to the publishing screen, the completed items and the one flagged authorization problem are waiting there for you to act on.
Important considerations
- A persistent job describes how RankGear coordinates work across screens — it is not a ranking signal, and nothing about it is scored by Google.
- Retries are bounded on purpose: a transient timeout may earn one longer attempt, but an invalid credential or bad target stops rather than repeating paid provider or publishing calls.
- Credentials and remote publishing targets need care; where possible, connection tests should be read-only, and secrets must stay redacted in status and diagnostics.
- Any provider data a job pulls is a comparative indicator on that provider’s own scale, not a Google score — correlation with rankings is not causation.
Related terms
Part of the RankGear glossary · how RankGear measures · the 870 factors.