Skip to main content

Monitor executions and retries

Section: DOC-CP-scheduling-execution#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: DOC-CP-scheduling-execution#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.

curl -X POST https://api.travila.ai/api/v1/scheduler/list-executions \
-H "X-API-Key: sk_your_key_here" \
-H "X-On-Behalf-Of: user_123" \
-H "Content-Type: application/json" \
-d '{
"scheduleId": "sched_a1b2c3d4e5f60718",
"pageSize": 20,
"statusFilter": "EXECUTION_STATUS_FAILED"
}'

Reference: List executions for a scheduled job · Request fields.

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

Recover a temporary receiver failure​

Section: DOC-CP-scheduling-execution#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:

curl -X POST https://api.travila.ai/api/v1/scheduler/create-job \
-H "X-API-Key: sk_your_key_here" \
-H "X-On-Behalf-Of: user_123" \
-H "Content-Type: application/json" \
-d '{
"name": "Critical alert",
"scheduleType": "SCHEDULE_TYPE_CRON",
"cronExpression": "*/5 * * * *",
"target": {
"url": "https://your-api.example.com/jobs/alert",
"kind": "alert"
},
"retryPolicy": {
"maxAttempts": 3,
"initialBackoffMs": 1000,
"maxBackoffMs": 10000
}
}'

Reference: Create a scheduled job · Request fields.

Restart future digests after fixing repeated failure​

Section: DOC-CP-scheduling-execution#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: DOC-CP-scheduling-execution. Section identities and revisions.