Redacted Diagnostics are troubleshooting details — error messages, request context, status codes, and retry decisions — with API keys, tokens, passwords, and other secrets stripped out, so a failure can be diagnosed and shared safely without ever exposing a credential.
| Term | Redacted Diagnostics |
|---|---|
| Category | APIs, Reliability and Publishing |
| Also known as | Sanitized Diagnostics |
| Where it appears | Bulk Runs and support logs |
What it means in RankGear
When a Bulk Run calls an external provider or publishes to your WordPress site, some requests fail — a page times out, a key is rejected, a target refuses the write. RankGear records the diagnostic context you need to understand what happened, but scrubs any secret material before it is written to the support log or copied out to share. What remains is the shape of the problem: the operation that failed, the status returned, whether a retry was attempted, and how a credential test resolved. What is removed is anything sensitive — the API key becomes a masked placeholder, the token and password never appear. That is what makes a diagnostic redacted.
How to interpret it
Read a redacted diagnostic to tell a transient failure apart from a configuration error. Use the four signals it preserves — the visible status, the diagnostic message, the retry decision, and the outcome of any credential test — together. A timeout with an attempted retry points to a passing hiccup worth re-running; an authorization failure with a masked-but-rejected key points to invalid setup that a retry will not fix. The redaction removes only the secret value, not the meaning: a line reading 401 unauthorized — key ****REDACTED still tells you the credential was refused, just without printing it.
| Signal in the diagnostic | What it tells you |
|---|---|
| Visible status | The outcome code or state — e.g. timeout, 401 unauthorized, 200 ok — that names what happened. |
| Diagnostic message | The human-readable context for the failure, with secrets masked. |
| Retry decision | Whether RankGear judged the failure worth another attempt, which separates transient from permanent. |
| Credential test | The read-only check of whether the key or publishing target is valid, isolating auth problems from run problems. |
Example
You launch a 400-URL Bulk Run that generates drafts and publishes them to your site. One page times out mid-request and the log records a single bounded longer retry, which succeeds. A second target — your image provider — returns an authorization failure, so RankGear stops calling it rather than burning repeated paid requests, and the support log shows 401 unauthorized — key ****REDACTED instead of the actual key. From those two lines you can re-run the timed-out page and go fix the provider key, without any secret ever landing in the log.
Important considerations
- Credentials and remote publishing targets need care: credential tests should be read-only wherever possible, so checking a key or a WordPress endpoint never changes live content.
- Secrets stay masked even when you export or forward a log to support — redaction is applied before the diagnostic is stored, not after, so there is no unredacted copy to leak.
- Redaction trims the secret, not the diagnosis: enough context remains — status, message, retry, credential test — to act on the failure with confidence.
- A redacted diagnostic is an operational record of API reliability and publishing, not a quality or ranking signal — it describes what happened to a request, not how a page will perform in search.
Related terms
Part of the RankGear glossary · how RankGear measures · the 870 factors.