Every principal knows the same uncomfortable truth about safety drills: the drill is the audit. Whatever's broken in your emergency communication chain — a Chromebook that hasn't been enrolled since summer, a webhook whose secret got rotated and never re-pasted, a color template that says "Lockdown" but shows up on screen as yellow — the drill is when you find out. And by then, staff have already watched the system fail in front of them, which erodes the very trust the drill was supposed to build.
The good news is that most drill failures are boring, mechanical, and preventable. They aren't a failure of the alert software or of staff training — they're a failure to check a handful of things before pressing the button. This checklist is the one that catches the boring stuff on paper, so the drill can catch the interesting stuff on campus.
- Ten specific things to verify in the 48 hours before any drill
- Each item takes 2–5 minutes and can be delegated to IT or a safety coordinator
- The whole list runs in under an hour and prevents ~90% of avoidable drill-day surprises
- Bookmark this and re-run it before every quarterly drill
Why the Pre-Drill Checklist Matters
Drills exist to expose the gap between "what we planned" and "what actually happens." That gap has two components: the human one (does staff know what to do?) and the technical one (does the alert system actually reach everyone?). The value of the drill is in the human side — the technical side should be a solved problem before the drill starts. Every minute of drill time your staff spends waiting for an alert that isn't arriving, or squinting at a device that's showing the wrong color, is a minute they aren't practicing the actual response.
The checklist below is written for principals and assistant principals to run — or to hand to a safety coordinator or IT liaison — in the day or two before a scheduled drill. It's not a training document and it's not a compliance form. It's a mechanical pre-flight check.
Assign the checklist to a single named owner — usually the school's IT liaison or the assistant principal running the drill. Ten items with ten different owners becomes zero items with zero owners. One person, one checklist, one hour.
The 10 Items
Each item below has a "what to check" line, a "how to check it" line, and a "what a passing result looks like" line. Work through them in order — the earlier items catch the failures that would make the later items impossible to verify.
-
1Item 1
Confirm every classroom device is enrolled and connected
Pull the device roster from your alert system's dashboard and cross-check it against your building's actual device inventory (Chromebooks, staff laptops, digital signs, SMARTboards). A device that's been sitting on a cart since May might not have connected yet — and it won't magically connect the moment the alert fires. Pass: the count in the dashboard matches the count you expect, ±2 for legitimately offline devices.
-
2Item 2
Trigger a test webhook and confirm the response
Fire your primary lockdown webhook — the one wired to the staff panic button — from a bookmarked test URL. Watch a laptop, a Chromebook, and a digital sign light up at the same time. Pass: all three devices show the alert within your target delivery window (usually under 10 seconds).
-
3Item 3
Verify every alert template's color and message
Open each template in the dashboard: lockdown (red), evacuation (orange), shelter-in-place (yellow), all-clear (green). Read the message text out loud. If the message says "hide" but your building's response plan says "shelter in place," fix the message today. Pass: color, title, and message match your written emergency response plan for each alert type.
-
4Item 4
Review campus fencing rules
If your district uses campus fencing to scope alerts to a specific building, open the hook editor and confirm every webhook is targeting the campuses you expect. A middle-school lockdown alert firing at the elementary school across town is the kind of misconfiguration that only shows up when you check. Pass: each webhook lists the correct campuses under its delivery mode.
-
5Item 5
Check delivery latency on a device of each type
Sit in front of a Chromebook, a Windows laptop, a Mac, an Android tablet, and a digital sign. Trigger a drill-mode alert. Time the delay from button-press to full-screen display on each device. Pass: every device shows the alert within your target window. If one platform is consistently slow, that's a network or agent-version issue worth investigating before the drill.
-
6Item 6
Confirm the dismissal path works from every device
On each device type, dismiss the drill alert the way staff would in a real incident (usually a click, a keyboard shortcut, or an admin remote-clear). A stuck alert that won't dismiss is worse than no alert at all — it means every affected classroom needs a device reset before the next class period. Pass: every dismissal method produces a clean return to the normal desktop within a second or two.
-
7Item 7
Verify staff-only vs. all-devices routing
If your district differentiates between staff-only alerts (e.g., medical alerts routed only to office and nurse devices) and all-device alerts (lockdown, evacuation), test one of each. Confirm the medical alert lands only on the office devices and doesn't fire on classroom Chromebooks. Pass: the routing matches the description on your emergency response plan.
-
8Item 8
Verify the drill-mode banner appears
Flip a template into drill mode and fire it. Every device should show a clear "DRILL" banner across the alert — the same alert UX as a real event, but visibly labeled. Staff should not have to guess whether this is real. Pass: the drill banner is visible on every device type at normal viewing distance.
-
9Item 9
Walk through the alert-log workflow
After the test fires, open the alert log in the dashboard. Confirm it shows the timestamp, the source webhook, the template that fired, and the number of devices reached. This is the record your district will rely on for after-action reports and, in some states, for compliance filings. Pass: the log entry is complete, accurate, and downloadable as a PDF or CSV.
-
10Item 10
Rehearse the all-clear
The alert most commonly forgotten in drills is the one that ends the drill. Fire the all-clear template (green) and confirm every device shows it and dismisses cleanly. Staff need to trust that when an alert clears, it stays cleared. Pass: every device that received the drill alert also receives and displays the all-clear.
Ten items. Each one is a two-to-five-minute check. If any one of them fails, you've caught a problem before the drill instead of during it — which is the entire point.
The Common Failures These Checks Catch
The list above wasn't invented in the abstract. Every item corresponds to a failure mode that has actually shown up in real districts running real drills. Here are the patterns worth flagging so you know what to look for.
Devices that "should be enrolled" but aren't
The most common cause is a device that was reimaged over the summer, or a new Chromebook cart that went out to a teacher without the alert client re-enrolled. Item 1 catches this before the drill exposes it in front of a classroom.
Panic buttons that stopped firing
Panic-button vendors occasionally rotate the secret key on their side, or a district IT admin rotates the webhook secret without updating the panic button's outbound configuration. The button still lights up; nothing happens on the receiving end. Item 2 catches this.
Templates that drifted from the emergency response plan
A well-meaning administrator updated the response plan in October but never updated the alert templates. The plan says "shelter-in-place, remain in classroom" and the template still says "evacuate to nearest exit." Item 3 catches this.
Campus fencing that includes the wrong buildings
The district added a new school this year and the middle-school lockdown webhook was never updated to include it. Or an old building was retired and the fencing still targets it, so the alert count in the log is misleadingly low. Item 4 catches this.
Slow devices that hide a real problem
One or two devices lagging by 30 seconds is usually a per-device issue. An entire building lagging by 30 seconds is a network problem — a captive portal, a proxy interception, a QoS rule pushing WebSocket traffic to the back of the queue. Item 5 catches the systemic version.
Sticky alerts that won't dismiss
An out-of-date client agent that got stuck on a modal dialog and won't return control to the desktop until it's force-quit. Rare, but painful when it happens on 800 Chromebooks simultaneously. Item 6 catches this.
None of these are software defects. They're all configuration drift, staffing turnover, or vendor-side changes that quietly accumulate between drills. The checklist is what catches them.
The Compare: With vs. Without the Checklist
If you're wondering whether the extra hour is worth it, here's the honest before-and-after.
Without the checklist
Roughly 40% of the drills we hear about have at least one visible technical failure — a stuck alert, a webhook that didn't fire, a device that never showed the message. Staff notice. Trust in the system drops. The next drill is more skeptical, not less.
With the checklist
When the ten items above are verified 24–48 hours before the drill, technical failures on drill day drop to under 5% — and the ones that remain are almost always caught in the log after the fact rather than being visible to staff during the drill.
The math is boring: one person, one hour, saves an all-hands drill from turning into an all-hands technical audit.
What to Document After the Drill
The checklist ends when the drill starts, but the value compounds if you use the drill itself to update the checklist. After every drill, document three things.
What worked exactly as expected
Not just "the drill went well" — specifically which alerts fired, which devices displayed them, and which staff responded appropriately. This is the baseline you'll compare against next quarter.
The alert-log export from Item 9 is your source of truth here.
What surprised you
Any device, staff behavior, or system response that wasn't what you expected. A specific classroom's SMARTboard was in the middle of a projector calibration and didn't display the alert. An office iPad wasn't in the alert roster because it's technically a personal device. These are the edge cases the checklist can be extended to catch next time.
Add each surprise as a new item to your local copy of the checklist.
What was slow or awkward
Not broken, just friction — the dismissal on Chromebooks takes an extra keystroke because of a Chrome policy update, the all-clear color looks yellow-ish rather than green on the older classroom monitors, the alert log takes 30 seconds to load. These are the items to bring to your alert vendor's support team.
Vendors that respond to friction reports are the ones worth staying with; the ones that don't are worth reevaluating.
The point of documenting is not to build a compliance folder — it's to build institutional memory. The principal who's running the drill next year should be able to read your notes and know exactly what to check.
When to Run This Checklist
The default cadence is: before every scheduled drill. That's usually quarterly, which lines up with the natural rhythm of the school year (start of year, mid-fall, mid-winter, end of spring). If your district runs more frequent drills, the checklist scales down — the first two items (device enrollment, primary webhook trigger) are worth checking monthly regardless.
Run the full checklist any time your district (a) rotates webhook secrets, (b) adds or removes a building from a campus, (c) upgrades the alert software's server or client version, or (d) changes vendors for panic buttons, digital signage, or any device platform. Configuration drift accumulates fastest right after a change.
The temptation with a checklist like this is to run it once, decide the system works, and never run it again. That's the failure mode. The checklist isn't a certification — it's a maintenance schedule. Ten minutes of drift a week compounds into a broken drill by the next quarter.
Where the Checklist Fits in the Broader Drill Plan
The pre-drill technical check is one of three things a principal is coordinating in the days before a drill. The other two are the staff notification (usually 24–48 hours ahead, so people aren't blindsided but the drill still catches ordinary behavior) and the after-action review (usually within a week of the drill, while memory is fresh). This checklist covers the technical side only — the human side is a separate conversation and a separate document.
A drill can pass every technical check and still be a bad drill — if staff panicked, if students didn't follow protocol, if the response plan itself has gaps. The checklist tells you the messenger is working. The drill tells you the message is landing. Both matter.
A principal who runs the checklist religiously, documents the drill honestly, and updates both the checklist and the response plan after each cycle is running a program, not a series of one-off events. That's the difference between a district that treats emergency communication as an annual chore and one that treats it as a continuous practice.
The Principal's Bottom Line
Emergency communication technology is not the interesting part of a drill. It's the part that has to work so the interesting parts — staff response, student behavior, response-plan gaps — can be examined honestly. When the technology fails during a drill, everything you actually wanted to learn from the drill gets buried under a technical post-mortem. When it works, the drill can do its job.
Ten items. One hour. Every quarter. That's the whole discipline. Bookmark this page, delegate the checklist to a named owner, and treat it as a standing pre-drill routine rather than a one-time setup. The drills your district runs in 2027 will thank you for it.
"If we ran the drill in an hour, what would we not know for certain about our alert system?"If the answer is "nothing," you're ready. If the answer is anything else, run the checklist first. The right principal's question
AlertIO's pre-drill dashboard shows device enrollment, webhook health, and template drift at a glance — so the ten-item checklist takes minutes, not hours. Start a free trial →