Automate the work. Prove it works first.

No. You pick a trigger, add filters from dropdowns, and choose actions — and twenty-six ready-made recipes mean you usually start from something that already works. Conditions are nested all/any/none groups with twelve comparisons, deliberately not a formula language: a formula would make “what will this rule actually do?” unanswerable without running it. Webhooks and placeholders are there for the rare job that needs to reach further, and they are optional.

Four ways, before it ever runs for real. The builder writes the whole rule back to you as a plain-English sentence as you build it. A dry run executes every step against a real object from your account and changes nothing, reporting what each step would do. A saved rule can be tested on demand. And a backtest replays your trigger and filters against your own recorded event history and tells you how often the rule would have fired in the last thirty days, and on what. Most rule engines in this category offer none of these.

In both directions. GitHub, Jira, Linear and PagerDuty events start rules — a workflow run that failed, a pull request merged, a release published, an incident escalated — and rules act back on them: open, label, assign, comment on or close an issue, merge a pull request, request a review, trigger or re-run a workflow, create a release or a deployment, set a commit status, transition a ticket, or create and comment on a Notion page. That is 32 actions through connected accounts, on top of the 47 built in.

It depends on how it failed, which is the point. A transient failure is retried with backoff — 30 seconds, then two, five, ten and fifteen minutes — and if it never comes good the run gives up, with the reason recorded, rather than hanging. A permission your credential does not have stops the rule immediately instead, names the permission the way the provider spells it, and notifies you, because four more attempts would be four identical refusals. Five failed runs in a row switch a rule off with the reason recorded. You can also tell any single step to carry on rather than stop the run.

Several things make that hard. Nothing runs until you save and enable a rule, and you can dry-run it first. Anything irreversible can sit behind Require approval, which holds the run until a named person says yes — and rejecting ends the run rather than skipping the step. A rule acts with a real person’s permissions rather than an unbounded service account. A run executes a frozen copy of the rule, so an edit mid-flight cannot change what is already going. And every run is in the audit log, with a deleted rule restorable for fourteen days.

Yes. Hourly, daily, weekly, monthly, every N minutes, or a raw cron expression if you prefer — in your organisation’s timezone, with the next few run times shown before you save so you can see you have not written 09:00 in the wrong zone. Rules can also be run by hand, or started by an inbound webhook that any tool can post to.

Three rules on the free plan, twenty-five on Pro and unlimited on Business — each with as many conditions and actions as you need. Every action is available on the free plan except the eleven that power servers up and down or change Cloudflare’s settings, which are Pro. Run history, dry runs and the backtest are not gated at all.