Trace the alarm path before trusting the notification.
This skill helps the AI separate current alarm state from journal history, audit events, logs, notification delivery clues, shelving, acknowledgement, and nuisance-alarm patterns.
Why it was made
- Keeps current alarm status separate from historical alarm journal records.
- Treats notification delivery as evidence to verify, not something to assume from pipeline configuration.
- Prevents unsafe tests by requiring sandbox recipients or explicit approval before real notifications are sent.
Common use cases
- Troubleshoot alarms that did not notify the right person.
- Review shelving, acknowledgement, clear, and escalation behavior.
- Find nuisance alarm patterns before changing priorities or delays.
- Prepare alarm evidence for a support or site review handoff.
Proof style
Validate the artifact, not the promise.
The skill does not infer delivery from pipeline status alone; it asks for status, journal, audit, log, and recipient-path evidence. Mailbox receipt or carrier delivery still needs SMTP/provider evidence.
Evidence
Alarm evidence workflow proof
The graphic is AI-generated for the site. The checks below come from sanitized alarm-pipeline evidence: runner health, a disposable alarm fixture, current status reads, alarm journal reads, acknowledgement and clear attempts, cleanup checks, and notification safety-gate tests. The evidence supports the workflow discipline; it does not claim customer notification delivery without a controlled sink, mailbox, carrier, or provider proof.
- health confirmed alarmStatusQuery, alarmJournalQuery, auditQuery, logQuery, and alarm include-shelved support before alarm investigation work.
- A disposable ManualHigh memory-tag fixture exercised active alarm status and journal reads on Ignition 8.1.53.
- The final journal query returned three bounded rows for the same eventId and preserved source, display path, priority, event state, and time fields.
- The test summary recorded unresolved ack/clear visibility gaps instead of turning partial evidence into a false pass.
- A notification safety gate accepted a named sandbox dry-run plan and rejected unsafe live recipients, phone/SMS, voice, and external webhook sends without explicit approval.
Example prompt
Use the runner to investigate why this high-priority alarm did not notify the expected roster last night.This is the kind of short instruction the skill is designed to make useful. The value is in the checks and Ignition-specific defaults the AI uses after reading the skill.
Expected output
- Queries current status, alarm journal, audit events, and focused Gateway logs.
- Separates alarm state, pipeline route, delivery clue, and missing proof.
- Produces a concise finding with safe next checks and no real notification tests unless approved.
Related workflows
Skills that pair with this one
Lifetime membership
Want access to this skill?
The one-time membership unlocks this skill, the full Ignition AI Toolkit, the Web Dev runner materials, setup docs, versioned downloads, and future Ignition 8.3 skills as they ship.
No subscription. Lifetime members keep portal access to the current toolkit and future skill releases, including planned Ignition 8.3-focused skills as they are added.