> ## Documentation Index
> Fetch the complete documentation index at: https://archie.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Creating a task
> Define a scheduled task in the Backend Console: name it, set a schedule, choose a target and its execution credential, and tune retries, timeout, and overlap behavior.
Create a task from **Backend → Scheduled Tasks → New task**. The form is grouped into the schedule, the target, and the execution options. This page walks each one.
## Name the task
Give the task a clear **name** and an optional **description**. Both are for you and your team — the name is how the task shows up in the list and the run history. You can also add **tags** to group and filter related tasks.
## Set the schedule
Pick how the task fires. There are three modes.
Describe the schedule in plain words — for example, *"every weekday at 8am"* — and Archie resolves it into a cron expression for you. Review the resolved expression before saving; it's the cron value that's actually stored.
Enter a cron expression directly, plus the **timezone** it runs in. The task fires on that recurring schedule.
Pick a single date and time. The task fires exactly once, then moves to **Completed**.
The **timezone** is an IANA zone (for example `America/Bogota`). Cron schedules are evaluated in that zone, so daylight-saving shifts are handled correctly. If you don't set one, the schedule runs in UTC.
Natural-language resolution just fills in the cron expression — it's a convenience on top of the cron mode, not a separate kind of schedule. Once resolved, the task stores and runs the plain cron expression.
## Choose a target
The target is what the task calls each time it fires. Pick one type.
Write a GraphQL **operation** — a query or mutation — directly, with optional **variables** as a JSON object. The operation runs against your project's GraphQL API. There's no saved-operation catalog; you author the operation on the task.
Reference a gateway route on your project by its **route ID** and **path**, with an HTTP **method**, an optional JSON **body**, and optional **headers**. This calls an internal [REST](/docs/features/backend/rest-api-explorer/overview) or [Custom API](/docs/features/backend/app-services/custom-apis) route by reference — never an arbitrary URL.
Call an arbitrary public API. Enter an absolute `https://` URL, an HTTP method, and an optional body and headers. Requests are screened by an anti-SSRF guard: only public hosts are allowed — private, loopback, and cloud-metadata addresses are blocked.
## Provide the execution credential
Every task needs an **API key** — the `Authorization` value it sends when it dispatches (for example `Bearer `). Create a role-bound key under [Settings → API Keys](/docs/features/backend/settings/api-keys) scoped to exactly what the task needs, and paste it here.
* On **create**, the credential is required.
* On **edit**, it's optional: leave it blank to keep the stored one. The credential is write-only — it's stored encrypted and never shown again.
Scope the API key to the minimum the task needs. A scheduled task runs unattended with whatever the key can do, so an over-scoped key is a standing risk.
## Execution options
Tune how each run behaves.
| Option | What it controls |
| --------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Overlap mode** | What happens when a run is still going and the next fire arrives: **Skip** drops the new fire, **Queue** runs it after the current one finishes, **Allow** lets them run concurrently. |
| **Timeout** | How long a single run may take before it's marked timed out. |
| **Max retries** | How many times to retry a failed run. You can also restrict retries to specific HTTP status codes. |
| **Max response size** | How much of the target's response body to capture into the run history. |
Choose **Skip** or **Queue** for jobs that must not run twice at once — a nightly rollup, a job that writes to the same rows. Use **Allow** only when concurrent runs are genuinely safe.
## Save
Saving creates the trigger in **Active** state and schedules its next fire. From the task list you can then [run it on demand, pause it, or review its history](/docs/features/backend/scheduled-tasks/run-history).
## Editing a task
Open a task and edit any field. Two things to know:
* Leaving the **API key** blank keeps the existing credential — you don't re-enter it to change the schedule.
* Edits use optimistic concurrency: if someone else changed the task since you opened it, your save is rejected so you don't overwrite their change. Reload and reapply.
## FAQ
No. Use the natural-language mode — describe the schedule in words and Archie resolves it to a cron expression, which you can review before saving. Cron mode is there when you want exact control.
Yes — that's what the execution credential is for. The task sends the API key you give it as the `Authorization` header on every dispatch. Scope that key to the task's needs.
External REST only allows public `https://` hosts. Private, loopback, and cloud-metadata addresses are blocked by the anti-SSRF guard. To call something inside your project, use a REST or Custom API target instead.
It moves to **Completed** and never fires again. It stays in the list with its run history until you archive it.