Execution logs
Use stage-specific check logs to diagnose file selection, download, restore, and probe failures safely.
Loading documentation…
Powered by heyo
Check logs explain what the project worker observed while processing an artifact. Use them to diagnose a failure; do not treat them as standalone proof that restored data is correct.
Depending on the check type and how far it progressed, the check can show:
A log can be empty or incomplete if the check failed before that stage started, timed out, or could not report its final output.
Job log batches use a best-effort telemetry path. A busy or disconnected agent can drop log batches, so gaps in the displayed log do not by themselves mean a stage was skipped. Lifecycle and result events follow a separate durable handoff; use the check's status, timings, and probe results for the outcome. The worker detail page's Logs tab reads the currently connected agent's container log on demand and is not a historical archive.
Use the terminal category—configuration, download/file, restore, probe, quota, infrastructure, timeout, or other—to choose the most relevant log.
Confirm the selected artifact, source, worker, database version, format and encryption settings, and referenced secret metadata. Correct a mismatch before retrying.
Later messages are often consequences of the first failed stage. Compare the timestamp and stage with the check's general timing information.
Save the schedule or cluster change, then start a manual check. The old check remains an accurate record of the earlier attempt.
Common categories include:
Do not place credentials in names, descriptions, paths, or probe text. Keep probes read-only and return only the value needed for comparison. Logs are diagnostic records that authorized project members may view.
Logs are supporting context. For a compact outcome record use Reports; for independently verifiable check data use Evidence and verification.