Skip to main content
Every time a task fires — on schedule or on demand — it produces an execution record. The run history is where you confirm a task is working, and where you look first when it isn’t. Open a task from Backend → Scheduled Tasks and select its Run history.

​
What a run records

Each execution captures:
  • Status and type (scheduled or manual).
  • Timing — when it was due to fire, when it started and finished, and how long it took.
  • Attempts — how many tries it took, including retries.
  • Result — the HTTP status returned, an error code and message on failure, and a response excerpt (the called service’s response body, truncated to the task’s max-response size).
  • A trace correlation ID that links to the Logs view for the full request and response.

​
Execution statuses

Skipped by lock is expected behavior, not an error — it’s how the Skip overlap mode prevents two runs at once. If you see it often, the task is firing faster than a run completes; widen the schedule, shorten the work, or switch the overlap mode.

​
Task health

A task’s list entry shows a health signal derived from its recent runs. An active task whose last runs all failed is flagged failing, along with how many consecutive failures it’s had and when it last succeeded. This is a display signal only — a failing task stays Active and keeps firing; the flag just makes a broken task easy to spot.

​
Run a task on demand

Use Run now to fire a task immediately without waiting for its schedule — handy for testing a new task or re-running after a fix. A manual run produces an execution marked as manual in the history, alongside the scheduled ones. The schedule is unaffected; the next scheduled fire still happens as planned.

​
Manage the lifecycle

From a task’s actions: Pausing is reversible; archiving is the retire path. Neither deletes the run history.

​
GraphQL API

Everything the UI does is a GraphQL operation against your project’s backend API, so you can manage tasks programmatically with the same calls. Your project and environment are taken from the auth token, not the request — so a token only ever sees its own project’s tasks. Mutations Queries
schedulerResolveSchedule is pure — it just turns a plain-language schedule into a cron expression and returns it. It’s what the natural-language mode in the create form calls before you save.

​
FAQ

Open its run history and read the failed execution: the HTTP status, error message, and response excerpt usually say why. For the full request and response, follow the run’s trace correlation ID into the Logs view.
The API key the task dispatches with was revoked or expired. Edit the task, paste a fresh key, and save. Rotate the key on the task before revoking the old one to avoid the gap.
No. It fires one manual run immediately and records it in the history. The recurring schedule is untouched — the next scheduled fire still happens on time.
Pause is a reversible off switch — enable it later and it resumes. Archive retires the task for good; it can’t be resumed. Both keep the run history.