Skip to main content

Monitor executions and retries

Section ID: Guide/jc45u7dce5#monitor-executions-and-retries

Find out whether a scheduled reminder or recurring task reached your endpoint. Check execution history for failed attempts, follow retries, and resume an automatically paused job after its target is healthy.

Find where the missing digest stopped​

Section ID: Guide/jc45u7dce5#execution-history

Use this recipe when a daily digest did not appear. Start with its saved schedule ID, intended firing time and the backend receiver’s work record.

  1. List executions for that schedule around the missing digest.

  2. If an attempt failed, inspect the HTTP result and error; fix the receiver or dependency it identifies.

  3. Check whether retries remain or the firing exhausted its attempts. If the job auto-paused, restore the receiver before resuming future work.

  4. If delivery completed, inspect the receiver’s accepted work and generated digest. A successful callback is not proof of a finished message.

  5. Reconcile an uncertain accepted action before manually replacing the digest, to avoid producing two.

Keep the schedule and execution references with the incident. The fields below explain the delivery portion of that investigation.

Every firing is recorded as an execution. Query the history to debug failures or monitor delivery.

This request isolates failed deliveries. To inspect a completed delivery as well, omit statusFilter and match the intended firing in the returned history.

Request example: List executions for a scheduled job. Example identifiers and values are illustrative; substitute authorized values.

Example request headers: X-API-Key: sk_your_key_here; X-On-Behalf-Of: user_123; Content-Type: application/json. Replace the credential and user placeholders with your own authorized values.

Use the execution fields and failure diagnostics to interpret the attempt you selected.

Recover a temporary receiver failure​

Section ID: Guide/jc45u7dce5#retry-policy

A receiver outage can recover within the firing’s retry window. Fix the underlying failure first and let the same firing continue within its configured limit; changing a retry policy is not a substitute for checking whether your receiver already accepted the work.

Choose the retry limits that fit this delivery’s useful lifetime.

To override the defaults, include a retryPolicy in your create-job request:

Request example: Create a scheduled job. Example identifiers and values are illustrative; substitute authorized values.

Example request headers: X-API-Key: sk_your_key_here; X-On-Behalf-Of: user_123; Content-Type: application/json. Replace the credential and user placeholders with your own authorized values.

Restart future digests after fixing repeated failure​

Section ID: Guide/jc45u7dce5#auto-pause

Restore the target, inspect the affected firing and then resume future digests. See pause state and thresholds for the exact behavior.

Document ID: Guide/jc45u7dce5