Campus Alert Archive

Analysis · Cross-corpus findings

What the archive shows

The archive preserves what 2,718 campus emergencies actually sounded like, message by message. Read across rather than one case at a time, the corpus has things to say: about what first alerts routinely leave out, how long the silences run, how often the record simply never closes, and what a wave of fake threats costs. This page is that cross-reading — 8 findings, each computed from the live data with its method, its limits, and its evidence attached.

Who wrote this, and how to check it

The analysis on this page is by Claude Fable 5, the Anthropic model that now owns the archive’s analytics layer. The corpus itself is compiled and fact-checked by other Claude models (the ingestion agents), and the per-alert message-element coding was produced by Claude Opus 4.8; Fable 5’s role is the cross-corpus computation, interpretation, and recommendations. None of it is human-reviewed, and it should be read the way you would read any analyst’s memo: as argued judgment over checkable evidence, not as ground truth.

Every figure in the claims, statistics, and charts of these findings is recomputed from the live corpus at each build; the surrounding prose and headlines paraphrase those computed figures and were checked against them by independent replication before publishing. Each finding states its inclusion rule, its n, its computation steps, and its known limits. The complete evidence sets are downloadable as findings.json, the raw corpus as cases.json, and the full method is documented on the methodology page. If a claim here can’t be reproduced from those files, it’s wrong — tell the maintainer.

Read this first · What this corpus is, and is not

2,718

cases

6,044

alert messages

26%

of messages verbatim-confirmed

68%

of cases dated 2022 or later

This is an AI-assembled research collection, not a census and not a random sample. Cases enter the archive because web sources documented them well enough to verify, which over-weights recent, serious, and heavily covered incidents. 543 cases are high-confidence (verbatim from an official source), 2,140 medium, and 35 low; 1,998 of the 6,044 messages carry exact timestamps.

Every finding below therefore names its denominator and inherits these biases. Statements about “the corpus” are exactly that — none of them are estimates of national rates, and we flag the places where the distinction bites hardest.

Finding 1 · Message content

Alerts say where; nearly half never say how bad

Of the 829 verbatim first alerts coded against the six warning-science message elements, 93% state a location but only 52% convey the hazard's potential impact and only 58% give any time element. 25% do not tell recipients what protective action to take.

93%

state a location

25%

omit protective-action guidance

52%

convey the hazard's impact

Location
93%
Source
75%
Hazard
75%
Guidance
75%
Time
58%
Impact
52%

Share of coded first alerts where each element is present (majority of 25 passes).

Warning research going back to Mileti & Sorensen's 1990 synthesis treats these elements as the components of a complete warning; the guidance element (what to do) is the one most directly tied to protective action. A quarter of the coded first alerts leave it out entirely.

The gap is not random: location — the easiest element to write under stress — is nearly universal, while impact and time, the elements that require judgment about the hazard itself, are the ones most often missing. That pattern is consistent with alerts being composed ad hoc rather than from templates that prompt for each element.

How this is computed

Who is counted (n = 829): Every alert in the corpus whose exact wording is verbatim-confirmed, that opens its case's alert sequence, and whose confirmed text is non-empty — the set coded by the Message Element Analyzer. (One confirmed first alert in the archive is genuinely blank — Pitt's ENS text on April 11, 2023 arrived with no body — and cannot be coded.)

  1. Take the committed message-anatomy consensus (data/message-anatomy-consensus.json): each coded alert was read in full by 25 independent Claude Opus 4.8 passes, each returning a present/absent verdict per element; an element counts as present by majority vote.
  2. For each of the six elements, divide the number of alerts where the element is present by the total number of coded alerts.
  3. Exhibit selection: 'complete' exhibits require a unanimous 25/25 present vote on all six elements; 'guidance missing' exhibits require a unanimous 0/25 guidance vote and a violence-type incident. Both lists are ordered newest first.

Conventions: median = middle value of the sorted list (mean of the two middle values for even counts); quartiles = Tukey hinges (the medians of the sorted list’s lower and upper halves); minute values round half-up before formatting. Recomputed from the live corpus at every build; reproduce it from cases.json.

Honest limits of this number
  • Element coding is AI-generated (25 Claude Opus 4.8 passes plus an arbitrator) and is not human-reviewed. Per-alert judgments can be wrong; every one can be audited on the Message Anatomy page, where all 25 votes and justifications are shown.
  • Only verbatim-confirmed first alerts are coded, so this subset over-represents institutions that publish alert archives and recent, well-documented incidents.
  • Presence/absence says nothing about quality: a vague 'take precautions' counts as guidance present.
The evidence (828 cases in the machine-readable set)

All six elements, unanimously present · 57 match

Selection rule (deterministic, not hand-picked): Every element present on a 25/25 vote; newest first.

Violence incidents whose first alert gave no guidance · 46 match

Selection rule (deterministic, not hand-picked): Guidance judged absent by all 25 passes (0/25), incident type in the violence group; newest first.

The complete slug list for this finding’s evidence set is in findings.json · Audit any alert's coding on the Message Anatomy page.

Finding 2 · Message form

The single text message is no longer the default

Across 813 verbatim first alerts, the median SMS runs 137 characters — but 36% of SMS first alerts sent since 2020 exceed the 160-character single-segment limit, and the median email first alert runs 606 characters, 4.4× the SMS median.

137

median SMS first alert (chars)

n=307

606

median email first alert (chars)

n=239

36%

of 2020s SMS first alerts exceed 160 chars

n=239

Sms
137 chars
Email
606 chars
Twitter/X
155 chars
Multi-channel
155 chars
Website
412 chars
Push
147 chars

Median character count of verbatim first alerts by channel (channels with ≥25 coded alerts).

The 160-character constraint shaped a generation of campus alerts — Ohio State's 2016 'Run Hide Fight' message runs 86 characters as stored. Concatenated SMS and app push have loosened that constraint, and a meaningful share of first alerts now spill past one segment.

Longer is not automatically better: what recipients see first is a lock-screen preview of roughly the first sentence. The first hundred characters still do most of the work, whatever the total length.

How this is computed

Who is counted (n = 813): Alerts with type 'initial' whose exact wording is verbatim-confirmed and non-empty, across all channels. Channel-specific figures use the subset sent on that channel (n shown per figure).

  1. Character counts are the length of the stored verbatimText (the validator enforces that the characterCount field matches). One confirmed alert with an empty body — Pitt's ENS text of April 11, 2023, which genuinely arrived blank — is excluded, since it has no wording to measure.
  2. Medians are computed per channel over verbatim-confirmed initial alerts; channels with fewer than 25 such alerts are omitted from the chart.
  3. The 160-character share uses SMS initial alerts from incidents dated 2020 or later; 'exceed' means strictly more than 160 characters.
  4. Exhibits: 'short but complete' = SMS first alerts, sorted shortest first, whose anatomy coding marks hazard, location, and guidance all present; 'longest' = SMS first alerts sorted longest first.

Conventions: median = middle value of the sorted list (mean of the two middle values for even counts); quartiles = Tukey hinges (the medians of the sorted list’s lower and upper halves); minute values round half-up before formatting. Recomputed from the live corpus at every build; reproduce it from cases.json.

Honest limits of this number
  • Verbatim recovery is uneven across eras: older alerts are underrepresented, and secondary sources sometimes preserve only the SMS variant of a multi-channel send.
  • Some archived 'SMS' texts may be the expanded web/app mirror of a shorter phone-delivered segment; where sources conflict the archive stores what the cited source shows.
The evidence (810 cases in the machine-readable set)

Short but complete · 175 match

Selection rule (deterministic, not hand-picked): SMS first alerts carrying hazard + location + guidance (per the element coding), shortest first.

The longest SMS first alerts · 307 match

Selection rule (deterministic, not hand-picked): SMS first alerts sorted by character count, longest first.

The complete slug list for this finding’s evidence set is in findings.json · Browse every verbatim-confirmed case.

Finding 3 · Speed

Where a first-alert time is documented, the median is about a quarter hour

202 cases in the archive (7% of the corpus) document the interval from incident start to first alert. Among them the median is 14 minutes (quartiles: 5–31); restricted to high-confidence cases it is 15 minutes (n=67).

14 min

median documented latency

n=202

5–31 min

interquartile range

15 min

median, high-confidence cases

n=67

The documented range is enormous: from same-minute weather warnings and UNC Chapel Hill's one-minute shooting alert in 2023 to Virginia Tech's 131 minutes in 2007 — the gap that drove the modern emergency-notification requirement in the Clery Act.

Treat the median as a description of well-documented incidents, not a sector benchmark: latency is most often reported precisely when it was unusually good or unusually bad.

How this is computed

Who is counted (n = 202): Cases whose top-level responseTimeMinutes field holds a number — a curator-entered value recorded only when sources document both the incident start and the first alert time.

  1. Collect responseTimeMinutes from every case where the top-level field holds a number; compute the median, and the quartiles as Tukey hinges (the medians of the lower and upper halves of the sorted values — the same rule as the published median, applied to each half).
  2. Repeat over the subset with confidence = high (cases whose alert text is verbatim from an official source).
  3. Exhibits: fastest = high-confidence, non-weather, non-hoax cases sorted ascending (weather warnings can precede impact, and a relayed false alarm's zero-minute 'latency' is not a response); slowest = all documented cases except missing-person incidents (where a long report-to-alert interval is structural), sorted descending.

Conventions: median = middle value of the sorted list (mean of the two middle values for even counts); quartiles = Tukey hinges (the medians of the sorted list’s lower and upper halves); minute values round half-up before formatting. Recomputed from the live corpus at every build; reproduce it from cases.json.

Honest limits of this number
  • Only 7% of cases document this interval, and they skew toward high-profile, heavily reported incidents. The other 93% are absent, not average.
  • The value is curator-entered from cited sources (timelines, after-action reports), not derived from the alert timestamps in this archive; individual values can be checked against each case's sources.
  • Incident 'start' is itself a judgment (first 911 call vs. first shot vs. first report); source conventions vary by case.
The evidence (202 cases in the machine-readable set)

Fastest documented (high confidence, non-weather) · 51 match

Selection rule (deterministic, not hand-picked): responseTimeMinutes ascending; high-confidence cases; weather types excluded.

Slowest documented (missing-person excluded) · 201 match

Selection rule (deterministic, not hand-picked): responseTimeMinutes descending; missing-person cases excluded.

The complete slug list for this finding’s evidence set is in findings.json.

Finding 4 · Sustained communication

After the first alert, the typical wait for news is about an hour

In the 211 cases where both the first alert and the next update carry timestamps, the median gap between them is 1 h; a quarter of these cases left recipients waiting more than 3 h 30 min. Only 31% followed up within 30 minutes.

1 h

median first-alert → first-update gap

n=211

31%

updated within 30 minutes

3 h 30 min

75th-percentile wait

Risk-communication guidance (CDC's CERC among others) emphasizes that people who receive a warning immediately begin seeking confirmation; a long silence after 'shelter in place' pushes them to rumor and second-hand sources.

In the exhibit lists below, the tightest documented cadences appear in serious, fast-moving incidents, while the longest silences cluster in ambiguous, slow-resolving situations — exactly when recipients are most uncertain about what to do.

How this is computed

Who is counted (n = 211): Cases with a timestamped initial alert and at least one timestamped update, where the update follows the initial alert by no more than 24 hours.

  1. For each case, take the lowest-sequence alert typed 'initial' that carries a timestamp and the lowest-sequence alert typed 'update' that carries one; the gap is the difference in minutes. 'Within 30 minutes' is inclusive (gap ≤ 30). The 75th percentile is the Tukey upper hinge (median of the upper half of the sorted gaps).
  2. Gaps of zero or less (data errors) and gaps over 24 hours (multi-day events where cadence semantics differ) are excluded; both exclusions are part of the published rule.
  3. Exhibits: 'long silences' restricts to emergency-notification cases with gaps of 12 hours or less (so a routine next-day status update after a resolved incident doesn't read as mid-emergency silence), sorted descending; 'tight cadence' requires a first gap ≤ 15 minutes and at least four timestamped alerts in the sequence.

Conventions: median = middle value of the sorted list (mean of the two middle values for even counts); quartiles = Tukey hinges (the medians of the sorted list’s lower and upper halves); minute values round half-up before formatting. Recomputed from the live corpus at every build; reproduce it from cases.json.

Honest limits of this number
  • Only about a third of alert messages in the corpus carry exact timestamps, and reconstructed sequences may omit intermediate messages — a documented 3-hour gap can be real silence or missing data. Case sources distinguish the two.
  • All-clear-only sequences (no intermediate update) are not in this denominator; the all-clear finding covers them.
The evidence (211 cases in the machine-readable set)

The longest documented silences · 162 match

Selection rule (deterministic, not hand-picked): Same inclusion set, sorted by gap descending.

Tight, sustained cadence · 11 match

Selection rule (deterministic, not hand-picked): First update within 15 minutes and ≥4 timestamped messages in the sequence.

The complete slug list for this finding’s evidence set is in findings.json.

Finding 5 · Closing the loop

In 45% of cases, no all-clear could be documented

1,505 of 2,718 cases include an explicit all-clear message; for the remaining 45% none could be found in the available record. Where both ends are timestamped (n=345), the median incident runs 1 h 41 min from first alert to all-clear — and hoaxes take roughly as long to clear as confirmed threats (unfounded reports: 1 h 25 min, confirmed threats: 1 h 42 min, confirmed hoaxes: 1 h 54 min).

45%

of cases have no documented all-clear

1 h 41 min

median first-alert → all-clear

n=345

1 h 54 min

median time to clear a hoax

n=79

Unfounded reports
1 h 25 min
Confirmed threats
1 h 42 min
Confirmed hoaxes
1 h 54 min

Median minutes from first alert to all-clear, by how the incident resolved.

The all-clear is the cheapest message in the sequence and the one that formally releases thousands of people from a protective action. Its absence from the record — whatever the operational reality was — means the public trace of the incident simply stops mid-lockdown.

Where hoaxes take roughly as long to close out as confirmed threats (medians above), that is the operational cost of a false report: clearing a building that was never dangerous consumes the same police hours as a real one.

How this is computed

Who is counted (n = 2,718): All cases in the archive for the documentation-gap figure; duration figures use the subset with a timestamped initial alert and a timestamped all-clear no more than 24 hours later.

  1. A case 'documents an all-clear' if any message in its sequence has type all-clear (the schema reserves that type for messages that explicitly lift restrictions; a message still saying 'avoid the area' is typed update).
  2. Durations are the lowest-sequence timestamped all-clear minus the lowest-sequence timestamped alert typed 'initial', excluding non-positive gaps and gaps over 24 hours; half-minute medians round half-up before formatting.
  3. Resolution groups use the normalization rules published in the methodology (e.g. any resolution containing 'hoax' or 'swat' groups as confirmed-hoax); groups with fewer than 20 timestamped pairs are not reported.

Conventions: median = middle value of the sorted list (mean of the two middle values for even counts); quartiles = Tukey hinges (the medians of the sorted list’s lower and upper halves); minute values round half-up before formatting. Recomputed from the live corpus at every build; reproduce it from cases.json.

Honest limits of this number
  • Absence of an all-clear in this archive is a documentation gap, not proof none was sent: reconstructed cases often preserve only the dramatic first messages. The share is best read as 'how often the public record goes silent', which is itself a finding about alert archiving.
  • The 24-hour cutoff excludes genuinely multi-day events (hurricanes, manhunts), whose 'duration' means something different.
The evidence (1,213 cases in the machine-readable set)

Clean, fast closes · 22 match

Selection rule (deterministic, not hand-picked): Unfounded reports cleared with a timestamped all-clear within 45 minutes, fastest first.

Casualty incidents where the record has no all-clear · 269 match

Selection rule (deterministic, not hand-picked): Confirmed threats with at least one casualty and no all-clear-typed message; newest first.

The complete slug list for this finding’s evidence set is in findings.json.

Finding 6 · Hoaxes & swatting

One in 8 recent cases in the archive ended as a confirmed hoax

281 cases in the archive resolved as confirmed hoaxes or swattings. Among cases dated 2022 or later, that is 12% (230 of 1,855), versus 6% of earlier cases — and a hoax still takes a median 1 h 54 min to clear.

281

confirmed hoaxes / swattings in the archive

12%

of cases since 2022 resolved as hoaxes

230 of 1,855

1 h 54 min

median hoax, first alert → all-clear

n=79

A false report buys everything a real one does: lockdown, sweep, fear, and an alert sequence indistinguishable from the real thing until the all-clear. The wave pattern is visible in the corpus — coordinated multi-campus bomb-threat campaigns against HBCUs in early 2022, and recurring swatting clusters since.

For practitioners the lesson is uncomfortable: the first alert cannot wait for verification, so the hoax playbook has to live in the later messages — honest uncertainty language, verification updates, and a disciplined all-clear.

How this is computed

Who is counted (n = 281): Cases whose recorded resolution normalizes to confirmed-hoax (the resolution string contains 'hoax' or 'swat'). Shares compare that set against all cases in the stated date range.

  1. Normalize each case's resolution field with the published rules; count cases normalizing to confirmed-hoax, split at incident date 2022-01-01 (2022 or later counts as 'since 2022').
  2. Hoax clear-time uses the same timestamped-pair rule as the all-clear finding (lowest-sequence timestamped initial → lowest-sequence timestamped all-clear, positive gaps of at most 24 hours), restricted to hoax cases.
  3. Exhibits: the HBCU wave is every hoax at an HBCU with incident type bomb-threat dated January–March 2022; 'longest sequences' sorts hoax cases by number of archived messages.

Conventions: median = middle value of the sorted list (mean of the two middle values for even counts); quartiles = Tukey hinges (the medians of the sorted list’s lower and upper halves); minute values round half-up before formatting. Recomputed from the live corpus at every build; reproduce it from cases.json.

Honest limits of this number
  • This archive is not a census: hoax waves were heavily covered and deliberately collected, which inflates their share relative to unreported routine incidents. The before/after comparison is between corpus compositions, not a measured national rate.
  • Some hoax-era cases remain typed under-investigation or unfounded; the normalization is conservative and counts only explicit hoax/swatting resolutions.
The evidence (281 cases in the machine-readable set)

The HBCU bomb-threat wave, early 2022 · 18 match

Selection rule (deterministic, not hand-picked): HBCU + bomb-threat + confirmed-hoax, January–March 2022; newest first.

Hoaxes that produced the longest alert sequences · 281 match

Selection rule (deterministic, not hand-picked): Confirmed hoaxes sorted by number of archived messages.

The complete slug list for this finding’s evidence set is in findings.json · Browse every hoax / unfounded case.

Finding 7 · Channels

Two channels carry the alert stream; WEA barely appears

SMS (35%) and email (34%) together account for 69% of the 6,044 archived messages. Wireless Emergency Alerts — which need no sign-up and reach every WEA-capable phone in the target area (users can disable every alert class except National Alerts) — appear in just 15 of 2,718 cases.

69%

of archived messages are SMS or email

15

cases with a WEA / IPAWS message

of 2,718

Sms
2,112
Email
2,080
Twitter/X
358
Website
308
Multi-channel
254
Push notification
239
Unknown
167
PA system
165

Archived alert messages by recorded channel (top 8).

Campus systems are opt-in or enrollment-based by construction, which is exactly their weakness during move-in week, campus events, and for visitors. WEA narrows that gap (it is on by default, though users can disable most alert classes), but requires the institution (or its local emergency-management partner) to hold alerting authority — and its near-absence from the archived record suggests it remains an exceptional tool, not a standard layer.

The archive records the channel each preserved message traveled on; institutions typically mirror one message across several channels, so the mix describes what survives in the record, not the full fan-out of every send.

How this is computed

Who is counted (n = 6,044): Every alert message in the archive, counted by its recorded delivery channel.

  1. Count archived messages by their channel field; percentages divide by the total message count.
  2. The WEA figure counts cases containing at least one message with channel wea-ipaws.

Conventions: median = middle value of the sorted list (mean of the two middle values for even counts); quartiles = Tukey hinges (the medians of the sorted list’s lower and upper halves); minute values round half-up before formatting. Recomputed from the live corpus at every build; reproduce it from cases.json.

Honest limits of this number
  • Channel is recorded per archived message. Where sources preserved only the SMS or only the email variant of a mirrored send, the other channels are invisible here — the mix is a floor on multi-channel practice, not a ceiling.
  • A small number of messages carry channel 'unknown' or 'multi-channel' where sources did not specify.
The evidence (15 cases in the machine-readable set)

The rare WEA activations · 15 match

Selection rule (deterministic, not hand-picked): Every case containing a WEA/IPAWS-channel message; newest first.

The complete slug list for this finding’s evidence set is in findings.json.

Finding 8 · Errors & corrections

Corrections are rare in the record — and fast when they come

28 of 2,718 cases (1.0%) contain an explicit correction message. Where the correction and the message before it are both timestamped (n=13), the median correction landed 16 min after the message it fixed.

28

cases with an explicit correction

of 2,718

16 min

median time to correct

n=13 timestamped

Wrong-campus sends, test messages that escaped, misidentified buildings: the failure modes in this set are mundane, and the institutions that recover well share one behavior — they name the error explicitly rather than silently issuing revised instructions.

The University of Hawaiʻi Mānoa case from the 2018 false ballistic-missile alarm sits in this set as the extreme reference point for what an uncorrected (then slowly corrected) false alert does to public behavior.

How this is computed

Who is counted (n = 28): Cases containing at least one message typed correction. Timing pairs each timestamped correction with the nearest earlier timestamped message (the highest sequence number below the correction's), keeping positive gaps of at most 24 hours.

  1. Count cases with any correction-typed message.
  2. For each timestamped correction, find the highest-sequence earlier message with a timestamp; the gap is the difference in minutes. Medians are over all such gaps.
  3. Exhibits sort those gaps ascending (fastest corrections first).

Conventions: median = middle value of the sorted list (mean of the two middle values for even counts); quartiles = Tukey hinges (the medians of the sorted list’s lower and upper halves); minute values round half-up before formatting. Recomputed from the live corpus at every build; reproduce it from cases.json.

Honest limits of this number
  • Corrections are certainly under-documented: a quietly superseding update often does a correction's work without the label, and sources rarely preserve embarrassing messages. Read the documented share as a floor on error frequency, not an error rate.
The evidence (28 cases in the machine-readable set)

Fastest documented corrections · 13 match

Selection rule (deterministic, not hand-picked): Timestamped correction gaps, ascending.

All cases with corrections · 28 match

Selection rule (deterministic, not hand-picked): Every case containing a correction-typed message; newest first.

The complete slug list for this finding’s evidence set is in findings.json.

For practitioners

What should a campus actually do with this?

The Practitioner Playbook turns these findings into nine concrete practices for the people who write and send campus alerts — each one tied back to the finding and the cases that motivate it.

Read the Practitioner Playbook

Figures on this page recompute from data/cases/ at every build; the archive grows continually, so numbers shift as evidence accumulates. Analysis and framing: Claude Fable 5 · corpus compilation: Claude ingestion agents · element coding: Claude Opus 4.8 (25 passes per alert). See the methodology.