Campus emergency alerts on digital signage override all screens within 5 to 30 seconds when triggered by InformaCast, Rave Mobile Safety, or Everbridge via the Common Alerting Protocol (CAP). Alerts display the threat type (active shooter, severe weather, fire, evacuation), shelter or evacuation location, and timestamp. Required for Clery Act timely warning compliance and for federal emergency alert system (EAS) interoperability.

A campus emergency management or IT-security team can use every screen across academic buildings, residence halls, dining halls, athletic facilities, and student services to push CAP-protocol emergency alerts triggered from InformaCast, Rave Mobile Safety, or Everbridge, with full-screen overrides for severe weather, active threat, evacuation, and shelter-in-place, replacing the patchwork of email-only alerts and fire panel sirens that miss most students.

How do you push an emergency alert to every screen at once?

You push an emergency alert to every screen by assigning an alert presentation to each device group, then triggering it from the CastHub dashboard, from an AI assistant through the CastHub MCP server, or from the REST Emergency API. On every device the priority is fixed: an alert overrides the schedule, and the schedule overrides the normal presentation. CastHub does not consume CAP feeds, so a CAP publisher calls the API instead.

The pattern is the same for any organization, not only a campus. A warehouse pushes a hazard notice to one plant group, a hospital pushes a code to one wing, a retail chain pushes an operational alert to every store, and a school district pushes a lockdown message to every building. The trigger is a dashboard action, a plain-language instruction to an assistant connected over MCP, or an HTTP call from a security system, alarm panel or CAP publisher that already knows something is wrong.

CastHub documents nine alert tools on its MCP server, each carrying a governance level in the tool documentation. Level 4 marks a critical action requiring multi-step approval, which is what a network-wide alert costs you before it fires. Two of the nine carry no published level.

Tool	What it does	Scope	Governance level as documented
start_all_alerts	Triggers an alert on all screens across the network and returns screensAffected and alertId	Entire network	Level 4, documented as a critical action requiring multi-step approval
stop_all_alerts	Stops all currently active alerts across the network and returns alertsStopped	Entire network	Level 3
start_group_alert	Triggers an alert on one device group and returns screensAffected	One device group, by groupId	Level 2
stop_group_alert	Stops an active alert on one device group	One device group, by groupId	Not labelled in the tool documentation
start_text_alert	Sends a text alert message to all screens, with an optional duration, and returns screensAffected and expiresIn	Entire network	Level 4
start_text_alert_for_group	Sends a text alert message to one device group, with an optional duration	One device group, by groupId	Level 2
assign_alert_presentation	Sets which presentation displays when an alert is triggered	One alert presentation, by presentationId	Level 2
assign_alert_presentation_to_default	Sets the default alert presentation for all groups and returns groupsAffected	Every group on the account	Level 3
remove_alert_presentation	Removes the assigned alert presentation, reverting to no alert content	One alert presentation, by presentationId	Not labelled in the tool documentation

The REST Emergency API runs at base https://casthub-webapi.azurewebsites.net and authenticates with a userEmail header and an integrationKey header, generated under Settings then Integrations, shown once, and resettable at any time, which deactivates the previous key. GET /api/v1/alerts/device-groups lists the groups you can target. PATCH /api/v1/alerts/device-groups/{deviceGroupId}/start-alert and the matching /stop-alert act on one group by id. The start-alert-by-group-name endpoint takes a deviceGroupName query parameter and acts on one group by name. PATCH /api/v1/alerts/device-groups/start-alert and its stop counterpart act on every screen on the account. That is the endpoint a CAP publisher, alarm panel or security platform calls, because CastHub receives the call rather than subscribing to a CAP feed.

How do school districts push emergency alerts to signage?

Most districts trigger signage from the mass notification system they already run. Rise Vision receives CAP from Raptor, Alertus, InformaCast and CrisisGo on its Advanced plan, and ScreenCloud receives CAP through Omnilert or Alertus. Airtame and Vivi appear on district shortlists, with no CAP path in the sources checked on September 1, 2026. CastHub does not receive CAP, and instead exposes a REST Emergency API your notification platform calls.

The practical question for a district is which side owns the integration. With Rise Vision and ScreenCloud the CMS subscribes and the district configures a named connector. With CastHub the notification platform, or a script the district owns, makes an authenticated HTTP call to one group, one group name, or every screen, which suits districts that already run a middleware layer and frustrates districts that want a vendor checkbox. The wider comparison for schools sits on the education digital signage guide.

What is the Common Alerting Protocol (CAP)?

CAP is the FEMA-standardized data format for emergency alerts. CAP-compliant systems can publish alerts that any CAP-compliant receiver can consume, including campus digital signage CMS. Used by the National Weather Service, IPAWS, and most major campus emergency notification systems (InformaCast, Rave, Everbridge). The protocol enables interoperability across alert sources and display channels, so a weather alert from NWS can render on the same screens as a campus-initiated lockdown.

How does InformaCast trigger digital signage?

InformaCast (Singlewire) publishes CAP-formatted alerts to subscribed receivers. The CMS subscribes via webhook or polling. On alert trigger, the CMS overrides all configured screens with the emergency layout. Setup requires admin access to both InformaCast and the CMS; one-time integration takes 1 to 2 hours. The same trigger architecture extends to campus wayfinding kiosks for emergency-route override at building entrances.

Alert source	Protocol	Typical latency	Common campus use
InformaCast (Singlewire)	CAP	5-15 sec	Mid-to-large universities
Rave Mobile Safety	CAP + REST	5-15 sec	Universities with Rave subscriptions
Everbridge	CAP + REST	5-15 sec	Large universities, multi-channel
AlertMedia	REST	10-30 sec	Mid-size campuses
Omnilert / Regroup / RAVE Alert	Webhook + REST	10-30 sec	Smaller campuses, community colleges
NWS via IPAWS	CAP	30-60 sec	Severe weather

What does Clery Act require for digital signage?

The Clery Act (Jeanne Clery Disclosure Act) requires timely warnings for crimes representing a serious or continuing threat to students and employees. Digital signage is one approved warning channel alongside email, SMS, and outdoor sirens. The CMS must support full-screen override and rapid activation, with a target of under 5 minutes from threat identification to warning display. The same compliance pattern applies to campus event displays when events trigger campus-wide alerts.

What types of emergencies override digital signage?

Active threat (lockdown), severe weather (tornado, hurricane), fire, hazardous material spill, building evacuation, missing student, and shelter-in-place. Each emergency type has a configured layout in the CMS. Trigger sources: InformaCast or Rave for campus-initiated alerts; National Weather Service via IPAWS for weather; local fire department for building-specific alerts. The same alert architecture handles manufacturing safety signage overrides on plant networks.

How fast does an emergency alert reach campus screens?

CAP webhook-triggered alerts reach screens within 5 to 15 seconds of publication, per the figures those platforms publish, and polling-based integrations within 30 to 60 seconds. Rise Vision says its alerts appear instantly and ScreenCloud calls its override instant, neither publishing a number. CastHub publishes no time-to-screen figure, so ask for one during a trial: the CastHub MCP server executes start_text_alert and assign_alert_presentation from a plain-language instruction.