Vom Ereignis zur verständlichen Nachricht
Viele Anwendungen können einen Fehler protokollieren. Das hilft wenig, wenn niemand rechtzeitig darauf schaut. Für ausgewählte Ereignisse nutze ich deshalb zusätzlich Benachrichtigungen. ntfy kann solche Meldungen über HTTP entgegennehmen und an abonnierte Themen weitergeben.
Eine gute Nachricht beantwortet zuerst die praktische Frage: Was ist betroffen, was ist passiert und muss jemand handeln? Für längere Protokolle reicht ein Link zur geschützten Detailansicht. Zugangsdaten und sensible Inhalte gehören nicht in eine Nachricht, die später auf dem Sperrbildschirm erscheinen kann.
Themen sind eine Ordnung, keine Zugangssperre
Ein Thema kann beispielsweise Sicherungen oder einen bestimmten Meldeweg bündeln. Ein schwer zu erratender Name ersetzt jedoch keine Berechtigungen. Bei einer eigenen Installation sollten erlaubte Leser und Sender ausdrücklich festgelegt werden.
ntfy unterstützt Benutzer, Zugriffstoken und Lese- beziehungsweise Schreibrechte auf Themen. Für einen automatischen Melder kann ausschließliches Schreiben reichen. Eine reine Anzeige benötigt dagegen Leserechte. Administration ist eine andere Aufgabe und sollte nicht beiläufig jedem Sender mitgegeben werden.
Zuerst die Sender vorbereiten, dann abschotten
Beim nachträglichen Einschränken eines laufenden Systems ist die Reihenfolge wichtig. Jeder bekannte Sender benötigt einen passenden Zugang. Anschließend muss seine Testmeldung den Server erreichen und auf dem vorgesehenen Gerät sichtbar werden.
Erst danach würde ich anonyme Zugänge sperren und Gegenproben durchführen. Ein gesperrter Sender kann sonst unbemerkt verstummen. Die Gegenprobe sollte sowohl unerlaubtes Lesen als auch unerlaubtes Schreiben abdecken. Im eigenen Betrieb müssen zusätzlich die erforderlichen Dateien für Berechtigungen und Nachrichtenspeicherung dauerhaft erhalten bleiben.
Die Besonderheit auf dem iPhone
Bei einem selbst betriebenen Server und der offiziellen ntfy-iOS-App ist für zeitnahe Hintergrundmeldungen ein zusätzlicher Weckruf über einen geeigneten Upstream nötig. Die Dokumentation beschreibt dafür Poll-Anfragen, mit denen die App zum Abruf der eigentlichen Nachricht aufgefordert wird.
Der eigene Server allein macht die gesamte Zustellkette dadurch nicht unabhängig von externen Push-Diensten. Ebenso muss die App den eigenen Server beim Abruf erreichen können. Ein vorhandener VPN-Zugang gehört daher in den Praxistest. Diese Voraussetzung sollte vor einer Empfehlung für wichtige Meldungen klar sein.
Den ganzen Meldeweg prüfen
Ein erfolgreicher HTTP-Aufruf ist zunächst eine Bestätigung an den Sender. Ob die Nachricht auf dem Handy erscheint, ist ein weiterer Schritt. Für die Abnahme würde ich deshalb das Telefon sperren, die App in den Hintergrund legen und eine eindeutig benannte Testmeldung auslösen.
Danach folgt ein Test im vorgesehenen mobilen Zugriffsweg. Meldungszeit und tatsächliche Empfangszeit werden verglichen. Ein zusätzlicher Ausfalltest sollte kontrollieren, ob ein unterbrochener Meldeweg erkennbar wird. Eine Warnung darf nicht ausschließlich von genau dem Weg abhängen, dessen Ausfall sie melden soll.
Wenige Meldungen, klare Bedeutung
Priorität und Formulierung sollten zur Dringlichkeit passen. Eine erfolgreiche Routineaufgabe braucht eine andere Aufmerksamkeit als ein bestätigter Ausfall. Wiederholte identische Meldungen können wichtige Informationen verdecken; eine verständliche Entwarnung gehört ebenfalls zum Ablauf.
Mein sinnvoller Einstieg wäre ein klar begrenzter Anwendungsfall mit einem Sender und einem Empfänger. Danach folgen Rechteprüfung, Test bei gesperrtem Telefon und Dokumentation der Abhängigkeiten. Erst wenn diese Kette funktioniert, würde ich weitere Dienste anschließen.