Escalation canvas

Draw the policy. Skip the config files.

Every monitor has a canvas. Draw a line from its down port, drop in the steps you want, and the flow runs exactly as it reads. What you see on screen is the policy, not a diagram of one.

It reads like it runs. There is no gap between the picture and the behaviour, so anyone on the team can check the policy without learning a config format.
Branching, waiting, repeating. Tiered escalation, quiet hours and keep-paging-until-acknowledged are all built from the same handful of modules.
One policy per monitor. A noisy internal job and a customer-facing API can behave completely differently, because they are not sharing a global ruleset.

Start free All features

01 · Logic modules

The pieces you build a policy from.

Logic modules shape the path an alert takes. Notify modules send it. Drop them on the canvas and connect them in the order you want them to run.

If / else branch

Route on a condition: whether the monitor is up or down, how long it has been down, whether it just recovered, whether it has gone unacknowledged, or whether a certificate is expiring soon. True and false paths run different steps.

Condition check

Run a live probe mid-flow over HTTP, ping, TCP or SSH and take the pass or fail path from the result. A point-in-time test rather than a tracked monitor.

Wait

Hold everything after it until the monitor has been continuously down for a set number of minutes. This is the building block of tiered escalation.

Repeat alert

While the monitor stays down, fire the following steps again on an interval. Keep paging until someone acts. Resets automatically on recovery.

Schedule gate

Only let the flow through during set hours and days in your timezone. Overnight windows are supported, so you can put noise behind it and keep the critical path always open.

Log and annotate

Write a note to the monitor timeline without sending an alert, which is a clean way to mark escalation levels in the incident history.

02 · What you can build

Patterns that usually need three tools.

Tiered escalation

Post to a channel immediately. Wait five minutes. If it is still down, page the on-call engineer. Wait ten more, then escalate to the next person.

Quiet hours that still let real outages through

Put low-priority notifications behind a schedule gate and leave the critical branch ungated, so nothing important is ever held back.

Keep paging until acknowledged

Branch on whether the incident has gone unacknowledged for N minutes, then repeat the page on an interval until somebody claims it.

Try to fix it first

Call an HTTP action to restart a service, wait, run a condition check to see whether it worked, and only page a human if it did not.

Warn before the certificate expires

Branch on certificate days remaining and post a reminder to a channel weeks before anything actually breaks.

Different urgency per service

Because each monitor owns its policy, a background job can post to a channel while a payment API pages someone directly.

Questions

Common questions

Do I need to write YAML or any config file?

No. Policies are built by dragging modules onto a canvas and connecting them. There is no config format to learn and no file to keep in sync with what is actually deployed.

Can one monitor have a different policy from another?

Yes. Every monitor has its own canvas. That is the point of the design: a noisy internal service and a customer-facing API can behave completely differently without fighting a single global ruleset.

What happens when the service recovers?

The monitor has an up port as well as a down port, so you can draw recovery behaviour explicitly. Repeat alert steps reset on their own, and PagerDuty incidents and Jira tickets opened by the policy resolve themselves using the same key.

How does the policy know it is a real outage and not a blip?

That is decided before the policy runs. A monitor can require several consecutive failed checks before it counts as down, so a single dropped request never starts an escalation.