● Demo, fictional data, no live systems ◀ All demos
ENG

Engine

UniFi · UptimeRobot · UPS events → Asana · auto-ticketing
poll #0 · idle
Pick an incident same engine, three ways a site fails
1 · Poll
Every 5 min: UniFi devices across all consoles, UptimeRobot monitors, live UPS events.
2 · Confirm
Flap protection. Must stay down 2 polls before filing (UPS alarms are already debounced).
3 · File
One incident, one ticket, titled by severity, with an SOP and a push to the on-call team.
4 · Resolve
Closes after 2 clean polls, then checks the close actually held.
Live feed: Cedar Ridge (CR12)
Engine run log
The Asana ticket it files SOP + live comment thread

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.