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, and the one that works while you are away.
You do not have to write cron. The 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. 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.
Whichever you pick, the builder compiles it and reads it back to you as a sentence. 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 daemon rather than by the app window, which is why they are the trigger that survives you closing Semantix — with the daemon installed as a service. 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.
The list is deliberately short and human — a curated set, not every signal the editor emits:
- a file saved, created, or deleted
- a reindex finishing
- a project being opened
- an agent run finishing
- before a tool runs, and after a tool runs
- a permission being requested
- switching 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. An event-triggered task fires when Semantix is open, and not otherwise. If you need work to happen while the app is closed, it needs a schedule — this is the one real difference between the two kinds, and it is worth choosing on purpose rather than discovering later.
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 task can be run on the spot, 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.
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 | yes — with the daemon installed as a service |
| Events (editor) | yes | no |
| By hand | yes | — |
Work that reacts to what you are doing wants an event. Work that should have happened before you sat down wants a schedule. Work you are still testing wants your finger on it.
Important
One setting overrides 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 when the studio is closed — whatever its trigger. If a scheduled task is not running overnight, check that box first.