Automations
An automation wakes kanman when something happens: CI turns red on main, a new CVE is found, a Jira issue reaches a status, an alert arrives on a webhook, or a time comes round. You add the context and, if you like, a skill; kanman decides what to do. Each automation has a rate limit, a dedupe window, an optional month budget and a pause switch.
Some things should always get kanman’s attention: the default branch turning red, a new vulnerability in a dependency, an alert from your monitoring, a Jira issue that is ready for development, or a weekly look at outdated dependencies. An automation says “when this happens, wake kanman with this context”.
kanman then decides what to do, the way it does with any other request: it may look into the cause, write a story, fix something, ask someone or decide that nothing needs doing. An automation never runs a fixed script.
Where you find them
Open a team, go to the Team tab and choose Automations (under Where work comes from). You can also type “Automations” in the command palette while a team is open. Everyone in the workspace sees a team’s automations; owners and admins create, change, pause and delete them.
Start from a template
Choose New automation and pick a template, or Start blank:
| Template | Wakes kanman when |
|---|---|
| CI red on main | the pipeline of a repository’s default branch turns red |
| New CVE | the maintenance sweep finds a new vulnerability (high or worse) |
| SonarQube gate failed | SonarQube’s quality gate fails |
| Alert from monitoring | one of the team’s webhooks receives a delivery, for example from Sentry or Grafana |
| Jira issue ready for development | a Jira issue reaches a status or label of the team’s pick-up rule |
| Weekly dependency check | every Monday morning |
| Morning triage | every weekday morning |
Every template comes with its own words for kanman. Change them as you like.
What an automation holds
- Name, so you recognise it in the list.
- When: the event. A webhook names one of the team’s webhooks (create one under Team > API and webhooks first). A schedule runs every hour, every day, on weekdays, once a week or on the first of each month, at a time in your time zone. CI fires when the default branch turns red, green again, or both, for one repository or all of them. A finding fires on new CVEs, failed SonarQube gates or both, from a severity you choose. A tracker automation fires for the statuses or labels you name; they must be part of the team’s pick-up rule under Team > Repositories and tracker.
- What kanman should know: your words, read as a request from the team. What arrives with the event (an alert’s text, an issue’s description, a finding’s title) is read as information from outside, never as an instruction.
- Skill to load (optional): one of the team’s skills, which kanman loads before it starts.
- Limits: how many times an hour it may wake kanman, how long the same event is ignored, and an optional month budget in euros.
Last fired and outcome
Each automation shows when it last fired and what happened:
- Woke kanman: kanman got the event with your context.
- Held: paused, Held: rate limit, Held: same event or Held: budget used up: the event was held and kanman was not woken. Nothing is lost silently: the line says why.
Below it you see how often it woke kanman this month and what kanman’s work on those wakes cost, against the budget if it has one. The cost is counted at list prices, the same way as on Budgets and cost.
Pause, edit, delete
The switch on each automation pauses and resumes it. A paused automation holds every event; a paused webhook automation also holds the deliveries to its webhook. Edit changes it; Delete removes it and its history.
Routines
Automations replace the former Routines page. Links to it open Automations.
Last updated: January 1, 0001
Open kanman