Skip to content

Runs

A run is the execution record for a job. Every time a job’s HTTP request is dispatched, a run is created that captures the complete request and response details.

What gets recorded

FieldDescription
response_statusHTTP status code returned by your endpoint
response_bodyFull response body (truncated for large responses)
response_headersResponse headers as key-value pairs
request_headersRequest headers sent (including any webhook signing headers)
request_bodyRequest body sent
started_atTimestamp when the HTTP request was dispatched
executed_atTimestamp when the response was received
duration_msTotal round-trip time in milliseconds
error_messageHuman-readable error description (if the execution failed)
failure_reasonCategorized failure reason (if the execution failed)

Failure reasons

When a job fails, Recuro classifies the failure into one of these categories:

ReasonDescription
timeoutYour endpoint did not respond within the configured timeout
connection_errorCould not establish a TCP connection (connection refused, reset, unreachable)
dns_errorDNS resolution failed (could not resolve hostname)
ssl_errorTLS/SSL handshake failed (certificate error, protocol mismatch)
http_client_errorYour endpoint returned a 4xx status code
http_server_errorYour endpoint returned a 5xx status code
invalid_urlThe configured URL is malformed or uses an unsupported protocol
assertion_failedThe response did not satisfy one or more success assertions
limit_exceededYour team’s monthly request limit has been reached
unknownAn unexpected error occurred

Viewing runs

In the dashboard

  • Jobs: Navigate to Jobs > [job] to see the run details including response status, body, headers, and timing
  • Crons: Navigate to Crons > [cron] > Executions to see the execution history. Cron executions record the same fields as job runs

Via completion callbacks

If a callback_url is configured, Recuro sends a POST with the execution summary after each run completes. See Jobs > Completion callbacks for the payload format.

Runs vs. cron executions

Jobs have runs (one per job, stored in the runs table). Crons have executions (one per scheduled firing, stored in the cron_executions table). Both capture the same data — the distinction is organizational:

  • A job has exactly one run (plus one run per retry attempt, each on its own job record)
  • A cron has many executions over its lifetime

Next steps