# Triggers

> Source: https://docs.clonepartner.com/using/triggers/

<!-- sources: ui/src/views/TriggersView.vue, src/server/api/triggers.ts, src/server/scheduler/cron.ts -->

# Triggers

A Trigger schedules a Job to run automatically — either on a recurring cron expression or once at a specific time. The Triggers screen lists every schedule, shows when each last fired, and is where admins create, edit, pause, and delete them. Triggered executions appear as Job Runs, the same as manual runs — see [Job runs](/using/job-runs/).

## Screen overview

Open **Triggers** from the sidebar. The page header reads "Schedule automated job execution." and offers a refresh button and, for admins, an **Add Trigger** button. A toolbar provides a **Search triggers...** input with a result count.

The list shows one row per Trigger:

- **Job** — the Job the Trigger runs.
- **Task** — the targeted task key, or **All** when the Trigger runs the full DAG.
- **Schedule** — the cron expression for recurring Triggers, or the fire time for one-off Triggers.
- **Status** — **Active** or **Disabled**; one-off Triggers also show a **One-off** badge, and a fired one-off shows **Completed**.
- **Last Triggered** — when the Trigger last dispatched a run. Sortable.

Admins also see per-row edit and **More actions** (Edit, Delete) controls.

<!-- screenshot: triggers-list | Triggers list with a recurring cron Trigger showing an Active badge and a completed one-off Trigger -->

## To create a trigger

1. Select **Add Trigger**. The **New Trigger** dialog opens ("Configure the trigger schedule below.").
2. Choose a **Job**. If the Job Template defines arguments, the dialog shows them read-only under **Job Arguments** — "Values configured when this job was created. Edit the job to change them."
3. Optionally narrow **Task** from **All tasks** to a single task key — "Run the full job DAG, or only the selected task subtree."
4. Pick a **Schedule type**:
   - **Recurring (cron)** — enter a five-field **Cron Expression** (the placeholder `*/5 * * * *` fires every five minutes).
   - **Run once at** — pick a **Run at** date and time in your local time zone. "Fires once at this time, then the trigger is disabled automatically." The time must be in the future.
5. Leave **Enabled** on and select **Save**. The Trigger appears in the list as **Active**.

<!-- screenshot: triggers-new-dialog | New Trigger dialog with a Job selected, Schedule type set to Recurring (cron), and a cron expression entered -->

Only admins and superadmins can create, edit, or delete Triggers.

## To pause or resume a trigger

1. Open the Trigger's edit dialog (the pencil button, or **Edit** in the row's **More actions** menu).
2. Toggle **Enabled** off to pause or on to resume, then select **Save**.

Pausing stops future dispatch immediately; it does not stop a Job Run that is already in progress. The **Job** field cannot be changed after creation — create a new Trigger for a different Job.

## To delete a trigger

1. Open the row's **More actions** menu and select **Delete**.
2. Confirm in the **Delete Trigger** dialog — "This will permanently delete this trigger. This action cannot be undone."

Deleting a Trigger removes only the schedule. The Job and its run history are untouched.

## How the scheduler dispatches runs

When a Trigger fires, the scheduler starts a Job Run for the Job (restricted to the selected task subtree if one is set) and stamps **Last Triggered**. Some ticks intentionally do nothing:

- **Disabled Triggers and non-active Jobs never fire.** A Trigger on an archived Job is skipped.
- **Overlap protection.** If the Job already has a run in flight, a recurring tick is skipped (Last Triggered still updates); a one-off Trigger instead retries every 60 seconds until the run clears, then fires. A run that has been in flight longer than the configured threshold is treated as stale and closed out — the threshold is the `max_inflight_age_minutes` scheduler setting, see [Server configuration](/deployment/server-configuration/).
- **One-off cleanup.** A one-off Trigger disables itself after firing and shows **Completed**. If the server was down at the scheduled time, the Trigger fires once at the next startup. Editing a completed one-off's time re-arms it.

:::callout{type="tip"}
A saved Trigger is not proof of a successful run. After changing a schedule, watch the [Job runs](/using/job-runs/) list for the next expected execution — overlap protection and archived Jobs can silently skip ticks.
:::

## Related

- [Job runs](/using/job-runs/) — where triggered executions appear
- [Jobs and job templates](/using/jobs/) — the Job a Trigger schedules
- [Server configuration](/deployment/server-configuration/) — scheduler settings such as `max_inflight_age_minutes`