Der Raketenalarm auf Hawaii: Wie aus einer Übung eine echte Warnung wurde

Kurz gesagt

Am Morgen des 13. Januar 2018 schickte die Hawaii Emergency Management Agency während einer Übung eine echte Warnung vor einer ballistischen Rakete an die Bevölkerung. Die Korrektur kam 38 Minuten später. Laut FCC-Bericht lag die Ursache in einer Kombination aus menschlichem Fehler und unzureichenden Sicherungen. Test und Echtwarnung standen im selben Menü, eine zweite Freigabe gab es nicht.

Kurz gesagt

  • Am Morgen des 13. Januar 2018 schickte die Hawaii Emergency Management Agency (HI-EMA) während einer Übung eine echte Raketenwarnung an die Bevölkerung.
  • Die Warnung ging um 08:07 Uhr Ortszeit hinaus. Die Korrektur kam um 08:45 Uhr, 38 Minuten später.
  • Laut dem FCC-Bericht vom April 2018 lag die Ursache in einer Kombination aus menschlichem Fehler und unzureichenden Sicherungen.
  • Nach Angaben, die HI-EMA an die FCC weitergab, glaubte der Mitarbeiter, der die Warnung auslöste, die Raketengefahr sei echt.
  • Test und Echtwarnung standen in derselben Oberfläche, im selben Dropdown-Menü. Eine zweite Person musste vor dem Senden nicht freigeben.

Die Geschichte: 13. Januar 2018, 08:07 Uhr

An einem Samstagmorgen erschien auf den Handys auf Hawaii diese Meldung: „BALLISTIC MISSILE THREAT INBOUND TO HAWAII. SEEK IMMEDIATE SHELTER. THIS IS NOT A DRILL.“ Auf Deutsch etwa: Ballistische Rakete im Anflug auf Hawaii, suchen Sie sofort Schutz, dies ist keine Übung.

Es gab keine Rakete. Die Meldung hatte die Katastrophenschutzbehörde des Bundesstaats, HI-EMA, während einer Übung verschickt. Den Vorfall untersuchte das Büro für öffentliche Sicherheit der US-Regulierungsbehörde FCC (Federal Communications Commission), das im April 2018 einen Bericht veröffentlichte. Die Uhrzeiten unten stammen aus diesem Bericht. Alle sind Ortszeit Hawaii.

38 Minuten

  1. 08:05Der Vorgesetzte der Nachtschicht startet beim Schichtwechsel eine unangekündigte Raketenübung. In der Aufnahme, die per Telefon abgespielt wird, fällt auch der Satz „this is not a drill“ (dies ist keine Übung).
  2. 08:07Ein Mitarbeiter der Tagschicht wählt im Dropdown-Menü die Vorlage für die echte Warnung und bestätigt. Die Warnung erreicht die Bevölkerung auf zwei Wegen: über EAS in Radio und Fernsehen, über WEA auf Handys.
  3. 08:12HI-EMA stoppt die weitere Verbreitung der Warnung. Eine Entwarnung („all clear“) sendet sie aber nicht.
  4. 08:20HI-EMA schreibt auf Twitter, dass es keine Raketengefahr gibt. Um 08:23 Uhr folgt ein Facebook-Beitrag.
  5. 08:31Die Korrekturmeldungen werden erstellt. Das dauert bis 08:44 Uhr.
  6. 08:45Die Korrektur geht an Handys und Sender. Seit der ersten Warnung sind 38 Minuten vergangen.

Der Bericht fasst diese Zeit in einem Satz zusammen: Die falsche Warnung brachte den Menschen auf Hawaii 38 Minuten Verwirrung, Angst und Ungewissheit.

Laut Zeitleiste waren die Telefonleitungen der Behörde zwischen 08:13 und 08:26 Uhr durch Anrufe aus der Bevölkerung überlastet.

Was der Mitarbeiter hörte

Am Anfang und am Ende der Übungsaufnahme stand der Hinweis „Exercise, Exercise, Exercise“ (Übung). In der Aufnahme fiel außerdem ein Satz, der gegen das Verfahren verstieß: „This is not a drill.“ Laut Bericht verstanden die anderen Mitarbeiter, dass es eine Übung war.

Der Mitarbeiter, der die Warnung sendete, sagte dagegen, er habe die Worte „Exercise“ nicht gehört, wohl aber den Satz „This is not a drill“. Der Bericht zitiert auch ein Interview des Mitarbeiters mit NBC News. Darin sagt er, er sei sich zu hundert Prozent sicher gewesen, dass seine Entscheidung richtig und die Gefahr echt war.

Ein Gespräch mit der FCC lehnte der Mitarbeiter ab. HI-EMA gab die Angaben aus seiner schriftlichen Stellungnahme an die FCC weiter.

Die Rolle der Oberfläche: Was der FCC-Bericht sagt

Der FCC-Bericht untersucht die Warnsoftware in zwei Absätzen. Die Befunde zur Oberfläche:

  • Dieselbe Oberfläche, dieselbe Anmeldung. Die Software verschickte echte Warnungen und interne Tests über denselben Bildschirm und mit denselben Zugangsdaten. Beides begann mit dem Button „Send Public Message“ (Meldung an die Bevölkerung senden).
  • Dasselbe Menü. Im Dropdown-Menü standen die interne Test-Raketenwarnung und die echte Raketenwarnung zusammen auf demselben Bildschirm.
  • Dieselbe Frage. Das Bestätigungsfenster fragte „Are you sure that you want to send this Alert?“. Laut Bericht war die Frage beim Test und bei der echten Warnung gleich.
  • Keine Vorschau. Das Fenster zeigte dem Mitarbeiter den Text der Meldung nicht.

Der Bericht vergleicht das mit der üblichen Praxis der Branche. Üblich ist, dass die Echtumgebung unter einer eigenen, bei der Anmeldung wählbaren Domain oder in einer eigenen Anwendung liegt. Manche Programme kennzeichnen interne Tests mit Wasserzeichen, Farbcodes und eigener Nummerierung.

Um fair zu bleiben, muss ich einen weiteren Befund des Berichts nennen. Der Bericht zählt zwei Schwächen der Software auf: Nutzer konnten eigene Vorlagen anlegen, und Test- und Echtumgebung waren ineinander verschränkt. Abgesehen davon entsprachen die Sicherungen der Software denen anderer Warnprogramme.

Für die Korrektur gab es keinen fertigen Weg

Die Warnung zu stoppen war möglich. Laut Bericht ließ sich eine falsch gesendete Warnung in der Software mit einem Klick zurückziehen, und die Behörde tat das um 08:12 Uhr. Ein Rückzug holt aber Meldungen, die schon auf den Handys sind, nicht zurück.

Die eigentliche Lücke lag woanders. Laut Bericht enthielt die Checkliste kein Verfahren, um einen Fehlalarm zu korrigieren. Der Bericht schreibt, dass diese Lücke zur Verzögerung der Korrektur beitrug.

Vor dem Vorfall gab es auch keine Schulung dazu, wie man eine Korrektur verschickt. Das Team traf sich um 08:27 Uhr, beriet, welchen Ereigniscode es verwenden sollte, und rief zur Bestätigung bei der FEMA an. Laut Bericht brauchte es die Erlaubnis der FEMA eigentlich nicht. Die Korrekturmeldungen entstanden zwischen 08:31 und 08:44 Uhr.

Der Bericht nennt auch die Maßnahmen, die HI-EMA danach ergriff. Vier davon sind für diese Geschichte wichtig:

  • Übungen werden von mindestens einer vorgesetzten Person beaufsichtigt.
  • Für Test und Ernstfall gilt eine Zwei-Personen-Regel.
  • Für Fehlalarme gibt es vorbereitete Korrekturvorlagen.
  • Der Softwareanbieter wurde gebeten, Test- und Echtumgebung klarer zu trennen.

Was wir wissen und was nicht

Nicht alle Erzählungen über diesen Vorfall decken sich mit der Quelle. Vor allem bei zwei Themen ist Vorsicht nötig: der Geschichte vom falschen Klick und dem Screenshot des Menüs.

ThemaStandAnmerkung
Datum, Uhrzeiten, 38 MinutenBelegtZeitleiste im FCC-Bericht: Warnung 08:07 Uhr, Korrektur 08:45 Uhr.
Test und Ernstfall standen im selben MenüBelegtDer Abschnitt zur Oberfläche im Bericht sagt das ausdrücklich.
„Der Mitarbeiter hat die falsche Option angeklickt“Widerspricht der QuelleLaut Bericht wählte der Mitarbeiter die echte Warnung. Nach Angaben, die HI-EMA an die FCC weitergab, hielt er den Angriff für echt.
Der verbreitete Screenshot des MenüsNicht der echte BildschirmLaut Civil Beat vom 16. Januar 2018 war das vom Büro des Gouverneurs verbreitete Bild nur ein Beispiel. Auf dem echten Bildschirm des Mitarbeiters gab es nicht so viele Optionen.
Wie der echte Bildschirm aussahUnbekanntHI-EMA veröffentlichte den echten Bildschirm aus Sicherheitsgründen nicht. Anhang B des FCC-Berichts ist eine Zeichnung des Menüs, wie es nach dem Vorfall aktualisiert wurde.

Die Bildfrage hat eine Fortsetzung. Laut Civil Beat lieferte HI-EMA am Dienstag, dem 16. Januar, ein zweites Bild, das ihr Sprecher „genauer“ nannte. Auch darauf stand eine Option für Fehlalarme, die aber erst nach dem Vorfall hinzugekommen war.

Keiner der Bildschirme, die im Internet als „das Menü“ geteilt werden, ist also der Bildschirm vom Morgen des 13. Januar. Deshalb habe ich auch die Demo fiktiv gestaltet.

Eine andere Quelle, die die Darstellung des Mitarbeiters bestätigt, habe ich nicht gefunden. Auch der Bericht formuliert mit „claims“ (behauptet). Auf dieser Seite gebe ich wieder, was der Mitarbeiter sagte, nicht was er dachte.

Probieren Sie es: Verhindern Sie den Fehlalarm

Unten erledigen Sie dieselbe Aufgabe auf zwei Bildschirmen. Versuchen Sie zuerst im schlechten Entwurf, die „Test Raketenwarnung“ zu senden, und wechseln Sie dann zum guten Entwurf.

Probieren Sie es: Verhindern Sie den Fehlalarm

Diese beiden Bildschirme sind fiktiv und keine Kopie der echten Oberfläche. Mit JavaScript können Sie zwischen den beiden Entwürfen wechseln und versuchen, eine Meldung zu senden.

Schlechter Entwurf: Test und Ernstfall in derselben Liste

Warnpanel · Vorlage wählen

Vorlagen

Das Einzige, was Test und Ernstfall trennt, ist das Wort „Test“ am Anfang der Zeile. Sende-Button und Bestätigungsfrage sind bei beiden gleich. Der Text der Meldung ist nirgends zu sehen.

Guter Entwurf: getrennte Umgebung, Vorschau und zweite Freigabe

Vorlagen der Übungsumgebung

Vorlagen der Echtumgebung

Diese Demo ist vollständig fiktiv. Sie kopiert nicht die echte Oberfläche auf Hawaii; der echte Bildschirm wurde nie veröffentlicht. Im schlechten Entwurf stehen Test- und Echtvorlage in derselben Liste, und die Bestätigungsfrage ist bei beiden gleich. Im guten Entwurf wählen Sie zuerst die Umgebung, sehen den vollständigen Text der Meldung, und eine echte Warnung braucht eine zweite Freigabe.

Es geht auch mit der Tastatur. In der Auswahl von Entwurf und Umgebung bewegen Sie sich mit den Pfeiltasten, bei den anderen Buttons reichen Tab und Enter. Jedes Ergebnis erscheint als Text unter der Demo.

Im guten Entwurf ist es schwerer, die falsche Zeile zu wählen, weil die echte Warnung in einer anderen Umgebung liegt. Der eigentliche Unterschied ist aber die zweite Freigabe. Selbst wenn der Mitarbeiter die Übung für echt hält, kann die zweite Person, die den Text liest, nachfragen.

Die Lehre für heute: Fehlervermeidung

Meist erzählen wir diesen Vorfall als Geschichte eines „schlechten Dropdown-Menüs“. Der Bericht sagt aber etwas anderes: Der Mitarbeiter glaubte, die richtige Zeile gewählt zu haben. Deshalb reicht die Lehre weiter als das Menü.

Falscher Klick und falsche Überzeugung

Unter Nielsens 10 Heuristiken ist die fünfte die Fehlervermeidung. Nielsen unterscheidet zwei Arten von Fehlern.

Ein Ausrutscher (Slip) ist ein unbewusster Fehler aus Unaufmerksamkeit. Ein Irrtum (Mistake) ist dagegen ein bewusster Fehler, der entsteht, wenn das mentale Modell der Person nicht zum Design passt.

Das Menü zu trennen, hilft meiner Meinung nach vor allem gegen Ausrutscher. Gegen einen Irrtum braucht es einen Schritt, der die Überzeugung der Person prüft. Eine Vorschau mit dem vollständigen Text der Meldung oder eine zweite Person, die den Text liest, leistet das.

Auch Nielsen empfiehlt, zuerst die teuersten Fehler zu verhindern. Eine Raketenwarnung an die Bevölkerung steht ganz oben auf dieser Liste.

Was Sie heute in Ihrem eigenen Produkt prüfen sollten

  • Vermischen sich Test- und Echtumgebung? In Panels, die Zahlungen, Massen-E-Mails oder Benachrichtigungen versenden, sollte der Testmodus durch Farbe und ein eigenes Banner abgesetzt sein.
  • Sagt die Bestätigungsfrage, was gesendet wird? Nielsens Artikel über Bestätigungsdialoge von 2018 kritisiert allgemeine Fragen vom Typ „Sind Sie sicher?“. Der Dialog sollte den Namen des Elements und die Folge nennen, und die Buttons sollten statt Ja/Nein die Folge benennen.
  • Erscheint die Bestätigung überall? Laut demselben Artikel wird ein häufig erscheinender Bestätigungsdialog ungelesen weggeklickt. Heben Sie Bestätigungen für ernste, unumkehrbare Aktionen auf.
  • Ist der Weg zur Korrektur vorbereitet? Auf Hawaii gab es kein fertiges Verfahren für die Korrektur, und das trug zur Verzögerung bei. Haben Sie eine Korrekturvorlage für eine falsch verschickte Kampagne oder Benachrichtigung?

Diese Prüfungen gehören zu einer heuristischen Evaluation. Wie man Fehlertexte schreibt, beschreibe ich im Muster Fehlermeldungen.

Meine Notiz

Wenn man diese Geschichte erzählt, liegt der Satz „ein ungeschickter Mitarbeiter hat den falschen Button gedrückt“ nahe. Der Bericht hält mich davon ab. Der Mitarbeiter sagt, er habe in der Aufnahme den Satz „dies ist keine Übung“ gehört und die Gefahr für echt gehalten.

In Audits sehe ich etwas Ähnliches. In Admin-Panels stehen „Live senden“ und „Test senden“ oft nebeneinander, in derselben Farbe. Das Team sieht darin kein Problem, weil es die beiden selbst nie verwechselt hat.

Mein Vorschlag ist immer derselbe: Zeigen Sie bei jedem Versand, der sich nicht rückgängig machen lässt, den vollständigen Text der Meldung und schreiben Sie die Folge auf den Button. Ist die Sache wirklich schwerwiegend, beziehen Sie eine zweite Person ein. Auf Hawaii kam diese Regel erst nach dem Vorfall.

Häufige Fragen

Wann war der Raketenalarm auf Hawaii?

Am Samstagmorgen, dem 13. Januar 2018. Laut FCC-Bericht ging die Warnung um 08:07 Uhr Ortszeit hinaus, die Korrektur um 08:45 Uhr, 38 Minuten später.

Hat der Mitarbeiter wirklich den falschen Button gedrückt?

Laut FCC-Bericht nein. Der Mitarbeiter sagte, er habe in der Übungsaufnahme den Satz „this is not a drill“ gehört. Nach Angaben, die HI-EMA an die FCC weitergab, hielt er die Gefahr für echt und wählte die Vorlage der echten Warnung. Ein Gespräch mit der FCC lehnte er ab.

Ist der im Internet verbreitete Screenshot des Menüs echt?

Nein. Laut Honolulu Civil Beat vom 16. Januar 2018 war das vom Büro des Gouverneurs verbreitete Bild ein Beispiel und enthielt mehr Optionen als der echte Bildschirm. Der echte Bildschirm wurde aus Sicherheitsgründen nicht veröffentlicht.

Was lässt sich aus diesem Vorfall für das Interface-Design lernen?

Trennen Sie Test- und Echtumgebung visuell. Zeigen Sie im Bestätigungsdialog den vollständigen Text der Meldung. Verlangen Sie bei unumkehrbaren Aktionen die Freigabe einer zweiten Person. Und bereiten Sie die Meldung, die einen Fehlversand korrigiert, vorher vor.

Quellen (4)
  1. FCC Public Safety and Homeland Security Bureau, Report and Recommendations: Hawaii Emergency Management Agency January 13, 2018 False Alert. abgerufen am 3. November 2026; April 2018; Zeitleiste, Ursachen (Abs. 18-23), Befunde zur Software (Abs. 26-27), Maßnahmen von HI-EMA (Abs. 39), Anhang B
  2. Marcel Honoré, Honolulu Civil Beat, Hawaii Distributed Phony Image Of Missile Warning Screen. abgerufen am 3. November 2026; 16. Januar 2018
  3. Jakob Nielsen, Nielsen Norman Group, 10 Usability Heuristics for User Interface Design. abgerufen am 3. November 2026; 1994; zuletzt überprüft am 30. Januar 2024; Heuristik 5, Fehlervermeidung
  4. Jakob Nielsen, Nielsen Norman Group, Confirmation Dialogs Can Prevent User Errors (If Not Overused). abgerufen am 3. November 2026; 18. Februar 2018