Workflow Monitoring and Alerting
Set thresholds on errors, run duration, LLM spend, and execution count, and be told when a workflow crosses one.
The problem
Automation platforms record failures, slow runs, and spend, but they never volunteer any of it. A workflow that started failing at 2am is found when somebody opens a dashboard, or when a customer reports it first.
How it runs today
Someone checks a chart on Monday, or a per-failure email arrives for every single error until the inbox rule that silences them gets written.
With Heym
The Alerts tab turns a metric into a rule: error count, run duration, LLM token or dollar spend, and execution count each get a threshold measured over a time window you choose, on one workflow or across everything you can access.
Inside the Alerts tab
Alerts is a tab in the Heym dashboard. Open it from the tab bar, go straight to /alerts, or jump there from the command palette.
- 1
Describe it, or pick a type
Write what you want in plain language, for example warn me if the invoice sync fails more than 5 times in 10 minutes, and Heym fills the whole form. Or choose one of the four types yourself: error threshold, workflow duration, token and dollar cost, or execution count.
- 2
Set the window and threshold
Every alert is judged over a time window rather than on a single event, because one failed run is noise and a burst inside ten minutes is an incident. Duration alerts measure the slowest run, the average, or the 95th percentile, with a minimum run count so a quiet window cannot fire on one outlier.
- 3
Choose what happens
Point the alert at any workflow to run when it fires. The observed value, threshold, window, and the runs behind it arrive as that workflow input, so Slack, email, and Telegram all work with nodes you already have. Alerts notify once and stay silent until the metric recovers, or repeat on an interval if you prefer.
- 4
Backtest before you save
The review step replays the condition against real history and reports how often it would have fired, along with the highest value it saw. A rule that would have fired four hundred times gets fixed before it is saved rather than after it wakes someone up.
- 5
Ask what happened
The firing history shows each breach with its observed value, threshold, and exact window. The Chat tab answers the same questions in plain language, including why a specific alert triggered and which runs caused it.
A workflow you can start from
Alerts and in-workflow error handling solve different halves of the same problem. The Resilient HTTP + Error Handler template catches a single failing request and notifies your team on the spot; an alert watches the pattern across a window and tells you when failures stop being one-offs.
Where control lives
The wizard backtests every condition before you save it, reporting how often it would have fired over the past day or week, so a threshold that is far too low is caught before it pages anyone. Alerts fire once and stay quiet until the metric recovers, and each firing records the observed value, the window, and the runs behind it.
Failures, slowdowns, and runaway spend surface on their own, with enough context attached to act on.
Built with these Heym capabilities
Common applications
Deployment and integration
- Self-host with Docker or Kubernetes, keeping data on your infrastructure.
- Connect your own model providers: OpenAI, Ollama, vLLM, and more.
- Integrate over HTTP, webhooks, Slack, email, and MCP tools.
- Expose finished workflows as APIs, portals, or MCP servers.
Have a process that fits this pattern?
Show us the workflow, data sources, tools, and human decisions involved. We will help map it to Heym.