Workflows
Automation across the product — when this happens, do that.
Delivery → Workflows automates sequences across AccelerUp.
Shape
trigger → conditions → actionsTriggers
| Trigger | Fires on |
|---|---|
| Alert fired / resolved | With severity and service filters |
| Incident opened / resolved | |
| Deployment started / finished | |
| Schedule | Cron-style |
| Webhook | Anything that can POST |
Actions
| Action | Does |
|---|---|
| Notify | Send to a channel |
| Open an incident | With a severity and a template |
| Run a command | On a server or a selection |
| Call a webhook | Anything outside |
| Update a status page | |
| Ask the Copilot | For a triage verdict |
Examples that earn their keep
Open an incident automatically for SEV1 conditions. Certain alerts always become incidents; doing it manually costs minutes at the worst time.
Post to the status page when a customer-facing service goes down. With a holding message. Somebody writes the real one a minute later.
Roll a log when disk-time-to-full drops below an hour. A rule action is usually better for this, but a workflow can span several servers and add a notification.
Guardrails
Workflows that run commands inherit the agent guardrails: give-up counter first, cooldown, and capped by profile.
Be careful with workflows that trigger on something they can cause. An action that produces an alert that triggers the workflow again is a loop, and the guardrails will stop it eventually — but "eventually" may be after a hundred notifications.
Audit
Every run is recorded: what triggered it, what it evaluated, what it did.
Where this behaviour lives: frontend/src/app/workflows/, backend/internal/handler/workflow_handler.go. If the code and this page disagree, the code is right — please fix the page.
Part of Delivery — Deployments, pipelines, releases and everything that ships code.