Faithful demo of Engine. The real service files this ticket body (a triage SOP, the affected equipment, a lifecycle
explainer, and a hidden beacon-entity tag for idempotent auto-close) and posts the comments below as the
incident moves. The creation and recovery comments mention the on-call team, so both land as a phone push.
Acknowledge it, mark it fixed by hand, or click Bring it back to watch it auto-recover.
Severity in the title. [OUTAGE] when a whole site or its outside-in monitor is down, [DEGRADED] when devices drop or a site is running on UPS battery but still reachable. A site that loses its primary ISP but stays up on LTE or 5G is still an outage (no redundancy left), relabeled so nobody drives out for a dead site. One incident, one ticket: a dark UniFi site and a down monitor for the same property share one ticket keyed by property code, and it only closes once every source that drove it reports clear.
Noise control. A device that drops 3 times in 14 days gets one sticky [CHRONIC] ticket at Known Issue that stays open across recoveries instead of a fresh alarm per drop. Short drops that recover before confirmation are logged as blips for analytics, never ticketed. Devices on Beacon's ignore list are skipped. During the weekly console auto-update window, new device tickets are held; during a property's planned maintenance window (set on the Beacon wall) the engine stands down for that site entirely, except power alarms.
Trust, but verify. A close is a write the engine does not fully control: a project rule can reopen it a second later. The engine checks on the next poll, and after 3 reopens it stops and leaves one comment asking a person to close it. A ticket held open because a device vanished from the API escalates with a comment after 3 days. And the engine only ever touches ticket kinds it files itself, so Beacon's maintenance and water tickets are never auto-closed.