HTTP actions

Try fixing it before you wake someone.

An HTTP action step calls an endpoint you control as part of the policy: restart a service, scale a group, trigger a runbook. Follow it with a condition check to see whether it worked, and only page a person if it did not.

Part of the flow, not a side channel. The action sits on the canvas between the outage and the page, exactly where the decision belongs.
Verify, then escalate. A condition check after the action tells you whether the fix took, so a human is only involved when one is needed.
Once per incident, or every check. Fire the action a single time, or repeatedly while the monitor stays down, depending on what it does.

Start free All features

01 · What you can trigger

Anything behind an endpoint.

Hesklo does not need access to your infrastructure. It calls a URL you already control, which keeps the blast radius on your side of the line.

Restart a service

Hit an internal endpoint that restarts the process that has stopped responding. The most common first automation and often the only one needed.

Scale a group

Call your platform or provider API to add capacity when a service starts failing under load rather than because it crashed.

Trigger a runbook

Kick off an existing automation in whatever tool already holds it, so the logic stays where your team maintains it.

Fail over

Promote a standby or switch traffic by calling the endpoint that already does it manually today.

Clear a queue or cache

Run the remediation you would run by hand at 3am, at the moment it is needed instead of an hour later.

Notify a system, not a person

Push the event into your own tooling when the right response is a system change rather than a message.

02 · Building it safely

Automation you can trust at 3am.

An action that fires blindly is worse than no action. The canvas gives you the pieces to make it conditional and verifiable.

Wait before acting

Put a wait step in front so the action only runs if the service has genuinely been down for a while, not on a transient failure.

Verify with a condition check

Run a live probe after the action and branch on the result, so the policy knows whether the fix actually worked.

Escalate on failure

The false path from that check is where a human belongs. They are paged with the knowledge that the automatic fix was already tried.

Log what happened

A log step writes to the monitor timeline, so the incident history shows the action fired and what followed it.

Control repetition

Fire once per incident for something like a restart. Fire on every check only when the action is genuinely idempotent.

Bearer token auth

The webhook destination supports an optional bearer token, so the endpoint you expose does not have to be open to anyone.

Questions

Common questions

Can Hesklo restart a service automatically?

Indirectly, and deliberately so. An HTTP action step calls an endpoint that you control, and that endpoint performs the restart. Hesklo never executes commands on your servers itself, which keeps the capability on your side where you can audit and limit it.

How do I know whether the automatic fix worked?

Follow the action with a condition check, which runs a live probe mid-flow and takes the pass or fail path from the result. Page a human on the fail path and you get automation that escalates honestly rather than silently failing.

Will the action fire repeatedly while the service is down?

That is your choice. Each action step fires once per incident by default, which is right for something like a restart. You can set it to fire on every check when the action is idempotent and repeating it is safe.

Is the endpoint I expose secured?

The step supports an optional bearer token, so your endpoint can require authentication. Beyond that, the endpoint is yours, so the usual controls apply: restrict the source, keep the action narrow, and log what it does.