Prompts
These are the audits this tool already knows how to do. Pick one from the menu in your client (in Claude Code they show up as slash commands; other clients have their own pickers), fill in any value it asks for, and you get the answer in plain language.
You don’t need to know an API. You don’t need to write a question. You don’t need to remember any technical names. The point of these is that the wording is figured out once, vetted, and reused — so the audit you run today and the audit you run next Tuesday line up.
Inventory & access
Section titled “Inventory & access”| Audit | What you fill in | Use it to ask |
|---|---|---|
offline_devices | Hours back (default: 24) | Which IP speakers / devices haven’t checked in recently? |
admin_access_audit | (nothing) | Who has administrative privileges in InformaCast? |
scenario_inventory | (nothing) | What notification scenarios are configured, and what do they target? |
site_overview | A site name or ID | What’s at one specific site — devices, users, configuration? |
distribution_list_audit | A list name (optional) | Who’s on each distribution list? (Leave blank to list all of them.) |
Activity & runtime state
Section titled “Activity & runtime state”| Audit | What you fill in | Use it to ask |
|---|---|---|
recent_notifications | Hours back (default: 24) | What notifications have actually fired recently? |
incident_status | (nothing) | Which incidents are open, and which just resolved? |
pending_confirmations | (nothing) | Which confirmation requests are still awaiting a response? |
system_health | Hours back (default: 24) | What system-health events have come in recently? |
tracking_streams_overview | (nothing) | Which location-tracking streams are currently active? |
Configuration & lifecycle
Section titled “Configuration & lifecycle”| Audit | What you fill in | Use it to ask |
|---|---|---|
bell_schedules | (nothing) | What bell schedules are configured, and when do they fire? |
integrations_inventory | (nothing) | What external systems are connected to this Singlewire? |
firmware_status | (nothing) | How are devices distributed across firmware versions? |
stale_users | Days back (default: 90) | Which users haven’t shown activity recently? (Cleanup.) |
offline_devices
Section titled “offline_devices”Find IP speakers and other endpoints that haven’t reported in for a while.
What you’ll see: a list of stale devices with name, how long since they were last heard from, and which site they belong to — followed by a one-line stale-vs-healthy summary.
You fill in: how many hours back to look. Defaults to 24. Want
a tighter check after a brief outage? Try 4. Looking at a slow
trend? Try 168 (a week).
Good for: weekly health checks, post-maintenance verification, troubleshooting “is this speaker actually online?”
admin_access_audit
Section titled “admin_access_audit”Lists every InformaCast user who currently holds an administrative role.
What you’ll see: users grouped by the role they hold, each with display name and email, then a per-role count.
Nothing to fill in.
Good for: quarterly access reviews, incident response (“who could have changed this?”), onboarding and offboarding sweeps.
scenario_inventory
Section titled “scenario_inventory”Lists every notification scenario configured in the system, plus what it would page if it fired.
What you’ll see: each scenario with its name, the recipient groups or device sets it targets, and the message template if one is set.
Nothing to fill in.
Good for: auditing what alarms can fire, documenting your policy surface for compliance, checking what depends on a recipient group before you change it.
site_overview
Section titled “site_overview”A short summary of one specific site.
What you’ll see: how many IP speakers and other endpoints are registered there, how many users are associated with the site, and any broadcast groups or scenarios assigned to it — laid out as a short bulleted summary you could drop into a status report.
You fill in: the site’s name or ID.
Good for: new-site verification, before a planned outage at a specific location, generating status updates for a particular building.
distribution_list_audit
Section titled “distribution_list_audit”Audit who’s on which distribution list.
What you’ll see:
- With no list name: every distribution list, with the total recipient count after expanding sub-groups, and a sketch of who the members are.
- With one list name or ID: a deep dive on just that list — full membership, recipient count, related sites or security groups, and any duplicates or orphans worth a second look.
You fill in: a distribution-list name to focus on, or leave it blank.
Good for: before changing a recipient group (“who else relies on this?”), quarterly recipient reviews, debugging “why did this person get paged?”
recent_notifications
Section titled “recent_notifications”Shows notifications and alarm activations that actually fired in a recent window.
What you’ll see: each notification with the scenario or template it used, who it went to, when it fired, and whether it was successfully dispatched. Grouped by hour or by scenario, whichever reads more naturally.
You fill in: how many hours back to look. Defaults to 24.
Good for: post-incident timelines, “did the test notification go out?”, weekly activity reports.
incident_status
Section titled “incident_status”Currently open incidents plus a recap of anything closed in the last day.
What you’ll see: each open incident with its ID, name, when it opened, and the site or facility responsible. Then the same shape for incidents closed in the last 24 hours, with the close time as well.
Nothing to fill in.
Good for: ER ops snapshots, daily safety standups, on-call shift handoffs.
pending_confirmations
Section titled “pending_confirmations”Confirmation requests that have gone out but haven’t been acknowledged yet.
What you’ll see: each pending confirmation with the request ID, the scenario or incident that triggered it, when it was sent, who hasn’t acknowledged, and any escalation rules in effect. Sorted oldest first so the most overdue are at the top.
Nothing to fill in.
Good for: verifying critical alerts were received, chasing slow responders, validating that escalation rules are firing.
system_health
Section titled “system_health”System-health events from the recent past, grouped by severity and component.
What you’ll see: events grouped by severity (info, warning, error, etc.) and by component (gateways, failover pairs, integrations, and so on). Each group shows a count and the most recent example. Ends with a green / yellow / red overall verdict based on the severity of unresolved events.
You fill in: how many hours back to look. Defaults to 24.
Good for: daily health checks, before scheduled maintenance windows, post-deployment verification.
tracking_streams_overview
Section titled “tracking_streams_overview”Active location-tracking streams that are running right now.
What you’ll see: each active stream with its ID, the user or device being tracked, the area or zone of interest, and when the stream started. Read-only by design — listing only, never starting, stopping, or modifying a stream.
Nothing to fill in.
Good for: “where is X right now” answers when a hospital uses CallAware or other tracking integrations, validating that the streams you expect to be running are actually running.
bell_schedules
Section titled “bell_schedules”Every bell schedule the system is configured to run.
What you’ll see: each schedule with its name, the times it fires (with weekday pattern), the audio or message it plays, the device set it goes to, and whether the schedule is currently enabled or paused.
Nothing to fill in.
Good for: before changing visiting-hours announcements, auditing recurring code-blue test cadence, sanity checks after holiday calendar changes.
integrations_inventory
Section titled “integrations_inventory”A consolidated picture of every external system connected to this Singlewire instance.
What you’ll see: counts and named entries across every integration category — Applications and Installed Applications, identity providers, notification extensions, gateways and failover pairs, CUCM clusters, IP cameras, Webex integrations, and inbound feeds (CAP, email, RSS). Anything that looks disabled or unhealthy is flagged.
Nothing to fill in.
Good for: vendor reviews, “what depends on us?” audits before infrastructure changes, security exercises mapping the external attack surface.
firmware_status
Section titled “firmware_status”Devices grouped by what firmware version they’re running.
What you’ll see: each firmware version with a count of devices on it and a few example device names. Versions that are significantly behind the most recent in the fleet are flagged as upgrade candidates. If a particular device class doesn’t expose firmware information through the API, the answer will say so explicitly rather than guess.
Nothing to fill in.
Good for: quarterly fleet upgrade planning, after a vendor security advisory drops, validating a recent rollout completed cleanly.
stale_users
Section titled “stale_users”Users who haven’t logged in or shown activity for a while.
What you’ll see: each stale user with their display name, email, when they were last seen (as a relative duration), and any privileged roles they currently hold. Privileged stale users are called out separately — those are higher priority. If the system doesn’t expose a “last activity” attribute, the answer will say so rather than fabricate one.
You fill in: how many days of inactivity makes someone stale. Defaults to 90.
Good for: quarterly access reviews, offboarding sweeps, post-incident tightening — anywhere “least privilege” matters.
What to know about these audits
Section titled “What to know about these audits”- The answers depend on what your Singlewire system actually
exposes. If your deployment doesn’t track, say, last-check-in
times on IP speakers,
offline_deviceswill tell you that — it can’t invent data. Same for firmware versions and last-login times: an audit will be honest about the gap rather than making numbers up. - They can’t change anything. Picking an audit doesn’t give Claude any extra power. The same read-only protections apply.
- The answer is the answer the LLM produces. It’s a careful summary of real data, not the data itself. For anything high-stakes, spot-check a result in the InformaCast admin console before acting on it. The Trusting the interpreter page covers this in more depth.
Need an audit that isn’t here?
Section titled “Need an audit that isn’t here?”If your team runs the same audit week after week and it isn’t on this list, it can be added — see Add a custom prompt. The aim is to grow this list deliberately: a new entry only when it’s a real, recurring need.
