Skip to main content
Scheduled Tasks let a project run work automatically — on a repeating cron schedule or once at a future time. Each task is a trigger: a schedule plus a target to call and the credential to call it with. Archie fires the target on schedule, retries on failure, and records every run. Use them for nightly rollups, reminder emails, data syncs, cache warming, or any job that should run without someone clicking a button. Open a project, switch to the Backend Console, and select Scheduled Tasks.

​
Core concepts

Trigger

One scheduled task: a name, a schedule, a target, and an execution credential. Triggers have a lifecycle — active, paused, completed, or archived.

Schedule

When the trigger fires. Either a recurring cron expression in a timezone, or a one-off run at a specific date and time.

Target

What the trigger calls: a GraphQL operation, a REST or Custom API gateway route, or an external HTTPS API.

Execution

One run of a trigger. Every fire — scheduled or manual — produces an execution record with its status, timing, and response.

​
How it works

Scheduled Tasks span three parts of the platform. Knowing the path helps when you’re debugging a task that isn’t firing.
1

You configure the task in the Backend Console

The Scheduled Tasks UI in the frontend collects the schedule, target, and options, and sends a GraphQL mutation to your project’s backend API.
2

The backend validates and forwards it

The backend API resolves your project and environment from the auth token — never from the request body — and forwards the call to the scheduler service. Because the tenant comes from the token, one project can’t create or read another’s tasks.
3

The scheduler service stores and runs it

The scheduler service persists the trigger, computes the next fire time, and enqueues the run. When the time comes it dispatches the target with your stored credential, applies retries and the overlap rule, and records the execution.
Everything you do in the UI — create, edit, pause, run now, browse history — is a GraphQL operation against the backend API, so the same actions are available programmatically. See the API reference for the operation names.

​
The trigger lifecycle

A trigger is always in one of four stored states: Failing is not a stored state — it’s a derived health signal. An active trigger whose recent runs all failed is surfaced as failing, with its consecutive-failure count and last success and failure times, so a broken task stands out without changing its status.

​
What a target can be

The first three call internal platform artifacts by reference, so they stay inside your project’s auth and gateway model. External REST is the only target that leaves the platform, which is why it’s restricted to public HTTPS hosts.

​
Execution credential

Every trigger carries an execution credential — the Authorization value (for example Bearer <token>) used when it dispatches. Create a role-bound API key with exactly the permissions the task needs, and give it to the trigger. The credential is write-only: it’s stored encrypted and never returned by the API or shown again in the UI. When you edit a task, leaving the credential blank keeps the stored one.
If the API key behind a task is revoked or expires, its runs fail — an execution is recorded with an identity-revoked status. Rotate the key on the task before revoking the old one.

​
Per-environment

Scheduled Tasks are scoped to an environment. A task defined in master is separate from one in another environment, each with its own schedule, credential, and run history. Create the tasks an environment needs in that environment.

​
Where to go next

Create a task

Walk through the schedule, target, and execution options step by step.

Run history & monitoring

Read execution statuses, run a task on demand, and manage its lifecycle.

​
FAQ

A Custom Function is code you write and deploy. A Scheduled Task is a schedule that calls a target — which can be a GraphQL operation, a gateway route, or an external API. A task can call an endpoint backed by a custom function, but the task itself is scheduling and dispatch, not code.
Yes — any cron expression is accepted, in the timezone you choose. You can also write the schedule in plain language and have Archie resolve it to a cron expression for you. See Creating a task.
Tasks live per-environment. Create the tasks each environment needs in that environment; credentials in particular are never shared across environments.
That’s up to the task’s overlap rule — skip the new fire, queue it behind the running one, or allow concurrent runs. See Creating a task.