Workflows

Workflows are simple automation rules: when something happens, do one or more actions.

Triggers

• A monitor goes down — after the usual two consecutive failed checks.
• A service goes down — the same detection that powers your service alerts.
• A deployment fails — a build or deploy that ended in failure.

Each workflow can run for any of your monitors/services, or only for one you pick.

Actions

Actions run in order and stop at the first failure:

• Restart service — restarts one of your services.
• Redeploy service — starts a new deployment of one of your GitHub apps.
• Notify — sends a notification to your email and subscribed alert channels, or to one specific channel.

Actions only ever touch your own services and go through the same logic and guards as the panel buttons.

Cooldowns and history

Every workflow has a cooldown (default 15 minutes): if it ran recently, the trigger is skipped and the skip is recorded. Each run — success, failure or skip — is written to the run history with a short log, so you can see what happened.

Example: When a service goes down on "api" → restart service "api" → notify #ops, with a 15-minute cooldown, keeps a flapping container alive without restarting it in a loop.

You can have up to 10 workflows per account.