Health Monitor - A ticket didn't open
You expected the health monitor to fire a ticket for an unhealthy subject — and it didn't. Here's how to figure out why. For operators investigating a missed alert.
Step 1 — confirm the monitor is enabled
Open Settings → Health Monitor. If Enable health monitor is off, the monitor isn't observing health events for your org. Turn it on, wait ~60 seconds, and re-check.
If observation is on but Publish tickets is off, the monitor is watching but not publishing. You'll see the subject's status on the Health Monitor page but no row in Tickets. Turn publishing on if you want tickets going forward — note that subjects already firing when you flip the switch won't retroactively get a ticket.
Step 2 — find the subject
Search for the device or integration on the Health Monitor page. Three possible states tell different stories:
- Healthy — the monitor never saw an unhealthy event. Either the subject isn't actually offline, or the upstream integration is reporting it as healthy. Confirm at the source (the device's vendor dashboard, the integration's status page).
- Pending open — the monitor saw the unhealthy event and is in its debounce window. Wait the configured open-debounce (default 60s). If the subject recovers inside the window, the ticket won't fire — by design.
- Firing — the ticket fired but maybe didn't reach the channel you were watching. Check Tickets directly.
If you can't find the subject at all on the Health Monitor page, the monitor hasn't observed it yet — devices that have never reported don't get a row.
Step 3 — check for an active silence
If the subject is Firing on the Health Monitor but no ticket exists in Tickets, it's likely silenced:
- Open Health Monitor → Silences (the tab on the Health Monitor page).
- Find the subject in the Active silences list. If it's there, the silence is suppressing new tickets.
- Click the delete icon at the right end of the row to end the silence early — the next unhealthy event will fire a ticket as normal.
See Silences for the full silence behaviour.
Step 4 — check the debounce policy
If the unhealthy event was brief (a few seconds), it may have ended inside the open-debounce window. Look at the subject's transitions timeline on its detail page — short healthy↔unhealthy bursts inside the window won't fire a ticket, by design. The debounce is platform-tuned by Neowit and isn't per-org — see Policy settings for the current value. If a subject regularly recovers just inside the window and you'd want a ticket anyway, talk to support.
Step 5 — check the cascade behaviour
If the subject is a device on an integration that already has an open cascade parent (a "Multiple devices offline on integration X" ticket), per-device tickets are intentionally suppressed. The device shows as a member on the parent's recovery checklist. Open the parent ticket from Tickets to see the device in the affected-devices list.
See Cascade rollups for when this kicks in.
Step 6 — still nothing?
If you've ruled out all of the above:
- The integration may not be reporting unhealthy events. Some integrations only emit "still alive" pings and don't actively signal failure. The monitor can't infer offline from silence alone unless the integration's connector tells it. Talk to support if you suspect this.
- A workflow may be auto-resolving the ticket the moment it opens. Open Tickets with the State filter set to Resolved and see if a fresh ticket appears + closes in quick succession. If a workflow's Resolve Ticket action is firing too eagerly, fix the workflow.