Running while Semantix is closed

This is the point of the Task Manager, and it is the claim most likely to be taken on faith. So here is exactly how it works and exactly when it does not.

What fires your tasks#

Not the app window. A small background daemon holds the schedules and fires them.

That separation is the whole trick. The window is where you write a task; the daemon is what runs it. They have different lifetimes, and the daemon's is the one that matters at 4am.

When you start Semantix, it looks for that daemon. If one is already running, it adopts it — and never shuts down a daemon it did not start. If none is running, Semantix starts one itself.

That single rule is what decides your answer:

If the daemon is installed as a service on your machine, it was already running before Semantix opened, so Semantix adopts it and leaves it alone on the way out. It keeps running after you quit, and after you log out. Your 4am task fires at 4am.

If it is not, Semantix started the daemon itself, and stops it again when you quit. Tasks fire only while the app is open.

Three things stop a task from firing#

The daemon is not running. Covered above, and the most common cause by a distance.

The task is marked project-only. A project task can be set to Only run while this project is open in the studio. A task marked that way will not fire when the studio is closed, whatever its trigger. If a schedule is not running overnight, check this before anything else.

Its trigger is an editor event. Editor events only exist while the editor is running. See Triggers.

When the machine cannot reach the daemon#

Semantix does not improvise here, and the design is deliberate enough to be worth stating.

Scheduled tasks do not fire. There is no local cache that fires on its own behalf, no "just this once from memory", and no catch-up storm when the connection comes back. One thing fires tasks, and if it cannot be reached, nothing fires.

The miss is recorded, not hidden. A run that did not happen appears in the history as a run that did not happen. You will not find a silent gap where a task should have been.

You are told in advance where possible. If the daemon becomes unreachable while something is due within the hour, Semantix says so rather than letting you discover it the next morning.

Two runs at once#

A task that fires every minute and takes ninety seconds would otherwise stack runs on top of each other. Each task chooses: Skip — the default — lets the current run finish and passes on this fire, while Allow starts the new one anyway.

Skip is also the blunt guard against a task that triggers itself: an agent that runs on file saved and then saves files. Leave it on Skip unless you know you want otherwise.