How automations work

An automation files tasks for you without anyone starting them: on a timer, such as a weekly status report, or when something happens elsewhere, such as a new issue in GitHub or a message in Slack. Automations live under Automation, on the Automations tab beside Playbooks.

Every automation reads as one sentence in three parts, and its page is laid out in that order:

This page explains the ideas. For the steps, see Create an automation, Choose what an automation runs on and Run, pause or change an automation.

Terms

Term	Meaning
When	What makes it run: a Schedule, or an event from a Webhook, GitHub, Gmail or Slack.
Target	Where each run files its work: a set of Projects or a set of Nodes.
Action	What each run does for every target. Task files one task per target.
Run	One time the automation ran, with the outcome for each target. Listed under Runs on its page.

Who sees automations

The Automations tab is shown only to Owners and Admins of your organization. Everyone else sees only Playbooks under Automation. Roles are explained in How team and access work.

When

Pick one When at the top of the editor:

When	Runs
Schedule	At named times (A cron expression, such as every weekday at 9) or every so often (A fixed interval, in seconds, minutes or hours). The Schedule line says when, in words, and when it runs next.
Webhook	Each time another system calls the automation's address, proving itself with its secret by HMAC signature or Bearer token.
GitHub	Each time a repository sends one of the Events you list, such as issues or pull_request, optionally narrowed to some Actions, such as opened.
Gmail	Each time an email reaches Jaah whose sender, recipient or subject contains what you set. Shown only to Jaah operators.
Slack	Each time someone mentions Jaah in one of the Channel IDs you list.

An event automation's source is fixed once it is created: a GitHub automation stays a GitHub automation. You can still switch it to Schedule.

For an event, the task's Title and description can quote the event with placeholders, such as {{body.issue.title}} for a webhook or GitHub event, {{email.subject}} for an email, and {{slack.text}} for a Slack mention. The hint under the description lists the ones each source offers.

Event automations also have their own sections: Setup for a webhook or GitHub automation (the address to give the other system, and its secret), Test (render a sample event before a real one arrives), a list of the events already filed, so a repeat is dropped, and State document. Under When, an event automation also has a Preflight that decides whether to file at all, Limits such as Rate limit per hour and Budget (USD), and settings that pause it after repeated failures or idle days.

Target

Target says where each run files its work, picked with one control whatever the kind:

• Projects — one task per project, filed into each.
• Nodes — one task per node. See Node targets.

Its three modes:

Mode	Runs on	A project or node added later
All	Every one in your organization.	Is included.
Specific	Only the ones you tick.	Is not included.
All except	Every one except those you tick.	Is included.

A target is a live rule, not a frozen list: it is worked out again at every run. All projects next week includes the project you add tomorrow, and All except skips only the ones you named.

While you choose, the control says what the rule covers right now: Will run on 3 of 6 projects. Closed, it reads as a sentence, such as 2 nodes: build-1, build-2 or All projects except docs.

If a project or node you named is deleted later, the automation keeps it, shown as a red chip with (removed) after its name, so you can see what changed. In Specific, a removed project makes its part of each run fail with Error; a removed node is skipped. Remove the chip to tidy the rule.

Node targets

Pick Nodes for work that belongs to the machine rather than to a repository: checking disk space, cleaning caches, reporting what is installed. Each run files one task per node, pinned to that node:

• The task runs on its node in a scratch folder, not in a project's worktree, and with no extra privileges on the machine.
• An offline node's task waits for the node to come back. A disabled node is skipped.
• The tasks land in your organization's built-in Nodes (your org) project, marked System. It holds node tasks only, can't be deleted or given a repository, and only Owners and Admins see it.
• An assignee who is not an Owner or Admin can't follow a node task there, so it is filed unassigned. The same happens on a project target whose assignee isn't a member of that project.

See How nodes work.

Action: Task

The Task action files one task for every target each time the automation runs. Its form is the same as when you start a task: the description, the depth and involvement buttons, files under Attach, an optional Assigned to, and under Advanced the Persona, Provider, Model, Priority, Project memory and Hidden. With exactly one project picked under Specific, it also offers Feature. Two things from the new-task form are not here: Dependencies and starting From Jira.

The tasks an automation files work like any other: they appear on the board, a runner works on them, and you read their results the same way. See How tasks work. They stay on the board if you delete the automation.

What a run skips

For a schedule, two rules decide what a run leaves out. The editor states them under When:

• Missed runs while down are skipped; the next run happens on schedule. If Jaah could not run a schedule at its time, it does not catch up afterwards.
• A target whose previous task is still open is skipped. A run files nothing for a project or node whose task from an earlier run is still open, so slow work never piles up. The other targets still get their task. A task waiting for your answer doesn't count as open here.

An event never skips for that reason. Instead, while a target already has as many open tasks as the Concurrency cap allows, the next event waits as Queued, and is skipped once the Queue depth is full.

Runs

Every run is listed under Runs on the automation's page, newest first: when, why it ran (Schedule tick, Event delivery or Run now), and a line such as 1 filed · 1 skipped: previous still open. Select one to see each target's outcome, grouped with what needs attention first:

Outcome	Means
Error	Filing this target's task failed. The reason is shown beside it.
Skipped	Left out on purpose, such as a previous task still open or a disabled node.
Not reached	The run stopped before it got to this target.
Queued	Waiting to be filed, such as an event held by its Concurrency cap.
Filed	Its task was filed. Select its task number to open it.

Status

Status	Means	What changes it
Active	It runs on its schedule or on each event.	Pause.
Paused	It runs nothing, but keeps its settings and its runs. Run now is unavailable.	Resume.
Failing	Its last run failed, a target failed, or Jaah stopped an event automation. The reason is shown beside the status.	Fix the cause; the next good run clears it. Resume restarts one Jaah stopped.

System automations

Some automations are Jaah's own machinery, marked System. Only Jaah operators see them, and their settings are read-only.