Triggers
When a task fires — on a schedule, on something happening in the editor, or by hand.
A trigger is the difference between a tool you operate and work that happens. Everything else about a task — what it runs, where it runs — only matters once something has decided to start it.
A task starts in one of three ways. In the new-task form the first two are the Trigger you pick — Time or Events — and the third is always available, whatever you chose.
Time — on a schedule#
The common case.
You do not have to write cron. The Schedule builder offers five shapes, and shows you the schedule back in plain English before you save it:
On-demand — no schedule at all. The task exists, fully configured, and runs only when you fire it — the preview reads Runs only when you trigger it. Useful for work you want defined once and repeated on your word rather than on a clock.
Every… — a fixed interval: every N minutes (1–59) or every N hours (1–23).
Daily — once a day at a time you pick.
Weekly — the same time on the days you choose. Weekdays only, or just Sunday, or three days out of seven.
Custom cron — a raw five-field cron expression, for the schedules the other four cannot say.
Times are local time, and the builder says so beside the field. Whichever shape you pick, it compiles the schedule and reads it back to you as a sentence with the cron beside it. A schedule you cannot check is a schedule you will get wrong, and the ones that matter run when nobody is watching.
Note
Schedules are kept by the background daemons, not by the app window — which is what will let them fire with Semantix closed once the daemons can run on their own. Today they stop with the window. See Running while Semantix is closed.
Events — when something happens in the editor#
A task can also fire on an event: something you did, rather than a time that arrived. Pick one or more under Fire on events:
- File saved, File created, File deleted
- Reindex completed
- Project opened
- Agent run finished
- Before a tool runs, After a tool runs
- Permission requested
- Switched channel
The obvious use is the one you would expect: run the linter when a file is saved, or start a review task the moment an agent finishes writing code.
Important
Editor events only exist while the editor is running: the Studio itself watches for them and fires the task. An event-triggered task fires when Semantix is open, and not otherwise.
Note
An event-triggered task runs exactly as you configured it. It does not yet receive details of the event that fired it, so a task triggered by File saved does not know which file was saved. Write the task so it works that out for itself.
By hand#
Any enabled task can be run on the spot with Fire now on its page, whatever its trigger. A schedule is a default, not a cage — and firing a task by hand is the fastest way to find out whether it does what you meant before you leave it to run at 4am.
Three things refuse a manual fire, and each one is recorded as a skipped run with its reason: the task is disabled (the button is greyed out — Enable the task to fire it), the task is marked project-only and that project isn't open, or the server can't be reached.
Choosing between them#
The question is not which trigger is better. It is whether the work needs you present.
| Trigger | Fires when Semantix is open | Fires when it is closed |
|---|---|---|
| Time (schedule) | yes | not yet — see Running while Semantix is closed |
| Events (editor) | yes | no |
| By hand | yes | — |
Work that reacts to what you are doing wants an event. Work that should happen on its own clock wants a schedule. Work you are still testing wants your finger on it.
Important
One setting narrows the whole table. A project task can be marked Only run while this project is open in the studio, and a task marked that way will not fire — by schedule, by event, or by hand — unless that project is open. If a task is not firing, check that box first.