A batch log is the timestamped diagnostic record RankGear writes while a bulk run executes, capturing every row transition, render result, provider error, retry, sleep pause, and engine exit so the run can be reconstructed and debugged after it finishes.
| Term | Batch Log |
|---|---|
| Category | APIs, Reliability and Publishing |
| Also known as | Bulk Run Log |
| Where it appears | Bulk Runs |
What it means in RankGear
When you launch a bulk run, RankGear processes many rows in sequence — each row typically a URL or keyword that gets fetched, rendered, and analyzed. The batch log is the running account of that work. As each row moves from queued to fetched to scored, RankGear appends a line to the log with the time it happened. Alongside those transitions it records what the render engine returned, any error a provider API sent back, whether a failed step was retried, how long the run paused between calls to respect rate limits, and how the engine finally exited. Because it is written continuously rather than assembled at the end, the log survives even when a run is interrupted, which is exactly when you most need to see what happened.
How to interpret it
Read the log to separate a transient failure from a broken configuration. A single row that timed out, then succeeded on retry, is noise — the network hiccuped and the run recovered. The same error repeating on every row points at setup: an expired credential, a wrong endpoint, or a publishing target that is unreachable. Use the four signals together — the visible row status, the diagnostic message, whether a retry was attempted, and the result of any credential test — before deciding to re-run. An authorization error that fails identically on the first three rows will not fix itself on the next three hundred, so stop and correct the configuration rather than burning paid API calls against it.
| Log entry | What it tells you |
|---|---|
| Row transition | The row advanced a stage (queued → fetched → rendered → scored) and when. |
| Render result | Whether the page rendered cleanly or returned an empty or partial document. |
| Provider error | The status or message a third-party API returned — the clue to transient vs. config faults. |
| Retry | A failed step was attempted again under a bounded policy rather than abandoned. |
| Sleep event | The run paused to stay inside a rate limit; expected, not an error. |
| Engine exit | How the run ended — clean completion, abort, or crash — and the exit reason. |
Example
You run a bulk analysis over 300 landing pages. In the batch log, row 47 shows a fetch that timed out at 14:02:11, followed by one longer bounded retry that succeeded at 14:02:26 — a transient stall the run handled on its own. Row 48, by contrast, shows a 401 from the provider, no retry, and a note that the credential test failed. That pattern tells you the API key is invalid, so RankGear stops re-hitting a paid endpoint that will only keep returning 401, and you fix the key before restarting.
Important considerations
- The batch log is an operational diagnostic, not a scoring or ranking metric — it tells you whether a run executed correctly, never how well a page will perform in search.
- Provider errors and statuses in the log reflect that provider’s API behavior and rate limits, which are comparative operational signals, not Google’s judgment of a page.
- Credentials and remote publishing targets deserve care: where possible, credential tests should be read-only, and secrets must stay redacted in the log so an exported or shared diagnostic never leaks a key.
- Sleep events and retries are healthy behavior under rate limits — do not read every pause as a fault; read the surrounding status and the engine exit to judge the run as a whole.
Related terms
Part of the RankGear glossary · how RankGear measures · the 870 factors.