Debug Failed Executions
Use execution history, retries, and response details to find why a scheduled job failed.
When a job fails, TrigRun gives you enough detail to work backwards from the failure instead of guessing.
1. Open the execution
From the workspace, open the execution history for the job and inspect the failed run. You can also fetch it directly:
The response includes attempts, final status, and the response preview when available.
2. Check the failure type
Start by looking at the broad failure class:
failedafter all retries usually means the target kept returning a non-success response or timing out- a single failed attempt followed by success usually means the retry policy did its job
- repeated connection failures usually point to DNS, TLS, or outbound reachability issues
For the execution lifecycle and retry rules, see Executions.
3. Inspect the request payload
Open the job configuration and verify:
- target URL
- HTTP method
- headers
- body
- timeout
If the request uses secret://name headers or dynamic variables, confirm the values still resolve the way you expect. See Secrets and Request Templates and Response Matching.
4. Re-run the execution
Once you have fixed the upstream issue, replay the execution:
That creates a new execution without modifying the original record.
5. Tighten the job
If the failure came from an API that returns 200 for logical failures, add response matching. If it came from an unstable upstream, tune retries and timeout settings.