Health Monitor - Policy settings
The two per-org switches that control whether the health monitor runs and whether it publishes tickets, plus an explanation of the timing rules that govern when it fires, recovers, and classifies a subject as flapping. For organizational admins setting up the health monitor for their org.
Where the settings live
Settings → Health Monitor. The page is only available to accounts that can configure your organization — if you can't see it, ask whoever administers Neowit for your org.
What you can change
The page has two switches. That's everything per-org:
Enable Health Monitor
The master toggle. Off means the monitor drops health events for this org — no live picture, no new tickets, no auto-resolves. Existing rows in Tickets and on the Health Monitor page stay readable but won't update. Within ~60 seconds of toggling, the change takes effect.
Publish tickets
Separate from enablement. With observation on but publishing off, you see the live picture on the Health Monitor page but no rows land in Tickets. Useful for the first few weeks while the monitor learns your environment.
Note: The Resolved-ticket retention is a Tickets-side setting, not a health-monitor one. It lives in Settings → Tickets. See Tickets retention.
How the timing rules work
The thresholds and windows below govern when the monitor fires, when it auto-resolves, and how it handles subjects that bounce. They're tuned platform-side by Neowit, not per org — the defaults serve every environment and per-org tuning would create more confusion than it solves. If your environment routinely runs into one of these rules in a way that hurts you, talk to support.
The current values:
Open debounce — ~60 seconds
A subject must be continuously unhealthy for this long before the monitor opens a ticket. Brief blips don't fire. If a subject recovers inside the window, the monitor cancels the pending open and the subject returns to Healthy.
Resolve debounce — ~60 seconds
After a Firing subject recovers, the monitor waits this long before auto-resolving the ticket. If the subject re-fails inside the window, the resolve is cancelled and the ticket stays open.
Reopen window — ~60 minutes
If a Resolved ticket's subject re-fails inside this window, the original ticket reopens instead of a new one being created. The previous resolution stays on the timeline. Outside the window, a fresh ticket fires.
Flap window + flap threshold — ~10 minutes / ~5 transitions
A subject crossing healthy↔unhealthy more than the threshold inside the window is flagged as Flapping. The flap count is exposed on the workflow trigger as ticket.flapCount, so workflows can branch on it without subscribing to a separate trigger.
Post-flap stable window — ~30 minutes
Once a subject is Flapping, the open ticket is held open until the subject has been continuously Healthy for this long. Auto-resolve is suppressed until then, so a brief in-between recovery doesn't auto-close the ticket and re-open it on the next dip.
Cascade fanout window + threshold
If many devices on one integration go offline together, the monitor rolls them into a single parent ticket. See Cascade rollups for the full behaviour.
What you observe vs what you change
If the monitor's behaviour doesn't match your environment — too many short-blip tickets, tickets closing before the team can act, flappy subjects not being detected — the right move is not to look for a hidden knob. The values above are what they are today, set by Neowit across all orgs. The right moves you can make:
- Silence subjects that are flapping for a reason you can't fix (see Silences).
- Turn off Publish tickets while you're tuning your environment (devices, sensors, integrations) and don't want the noise.
- Talk to support if you have a genuine reason to think the defaults are wrong for your org. The values evolve over time as we see real-world signal.