Hesklo
Home/Features/Noise control
Noise control

A real outage gets through. Nothing else does.

An alerting tool people ignore is worse than no alerting tool. These are the controls that keep the signal high: confirm before paging, dampen a flapping service, and decide whether a step fires once or keeps going.

  • Confirm before paging. Require several failed checks in a row before a monitor counts as down, so a single blip never starts an escalation.
  • Flap dampening per step. A cooldown on each notify step means a service bouncing up and down does not turn into a hundred messages.
  • Once or every check. Each step fires once per incident by default, or on every matching check when you want a steady drumbeat.
01 · Before an alert exists

Deciding what counts as down.

The cheapest noise to remove is the alert that is never created. Confirmation happens at the monitor, before any policy runs.

Consecutive failure threshold

Require a number of failed checks in a row before the monitor is marked down. One dropped request or one slow response does not qualify.

Per-monitor timeouts

Set how long to wait before a check counts as failed, so a genuinely slow endpoint is judged on its own terms rather than a global default.

Its own interval

A critical API can be checked frequently and a low-traffic page rarely, which keeps both the signal and the cost proportionate.

Maintenance windows

Pause a monitor during planned work so a known outage pages nobody, with an optional auto-resume time.

02 · Once the policy runs

Controlling how much it says.

Flap dampening

A cooldown per notify step. A service oscillating between up and down sends one message rather than one per transition.

Fire once per incident

The default for every notify and action step. One outage produces one message per destination unless you ask for more.

Fire on every check

The opposite setting, for when you want a repeated signal while a service is down rather than a single notification.

Repeat alert on an interval

A deliberate drumbeat that keeps paging until someone acknowledges, which is noise you actually want.

Schedule gates

Hold low-priority notifications to working hours and leave the critical branch open around the clock.

Log without alerting

Write a note to the monitor timeline instead of sending a message, so an escalation level is recorded without adding to the noise.

Questions

Common questions

What is flap dampening?
A cooldown applied to a notify step. If a service is oscillating between up and down, dampening stops each transition from producing its own message. You get one alert about an unstable service rather than a hundred.
How do I stop a single failed check from paging someone?
Set the monitor to require several consecutive failed checks before it counts as down. Until that threshold is met, no incident is created and no policy runs, so a brief blip is invisible.
Can I get repeated alerts on purpose?
Yes. A notify step can fire on every check rather than once per incident, and a repeat alert module fires the steps after it on an interval while the monitor stays down. Both are deliberate ways to keep paging until someone acts.
Will alerts still reach me during planned maintenance?
Not if you pause the monitor with a maintenance window. It keeps its history, pages nobody while paused, and resumes exactly as it was, optionally at a time you set in advance.
Keep reading

Related features

Alerting people will actually read.

Tune the thresholds, dampen the noisy steps, and let the genuinely urgent alerts through.