Alarmregeln

Alarmregeln gehören zu Pro und Team. Die Uptime-Checks eines kostenlosen Kontos zeigen ihre Ergebnisse, senden aber keine Alarme.

Jede Regel, die Cloud Viewer für dein Team auswertet. Wie du einem Alarm von der Mitteilung bis zur Ursache folgst, steht unter Wenn etwas Aufmerksamkeit braucht.

So liest du die Tabellen

Spalte	Bedeutung
Mitteilung	auf dem iPhone der Titel der Push-Mitteilung, nach Critical: oder Warning:. Android zeigt stattdessen die Zusammenfassung des Alarms als Titel
Regel	zuerst der `rule_key`, dann der interne Name der Regel. Die App zeigt den `rule_key` unter dem Titel des Alarms (Warnung · disk_space_low), Webhooks senden ihn als `alert.rule`, PagerDuty als `custom_details.rule`
Schwere	kritisch oder Warnung
Löst aus, wenn	die Bedingung und wie lange sie anhalten muss, bevor der Alarm ausgelöst wird

Die Regeln werden alle 30 Sekunden ausgewertet. Die Schwellwerte sind für jedes Team gleich. Selbst festlegen kannst du nur das Antwortzeit-Budget eines Checks und das Höchstalter eines Jobs.

Server: Hetzner-Cloud-Metriken

Für Cloud-Server in einem verbundenen Projekt, aus den Metriken, die Hetzner für sie meldet. Dedizierte Server haben keine Hetzner-Metriken, deshalb decken diese beiden Regeln sie nicht ab.

Mitteilung	Regel	Schwere	Löst aus, wenn
server offline	`host_offline` · `HostOffline`	kritisch	Hetzner führt den Server als laufend, hat aber seit mehr als 3 Minuten keine Metriken für ihn geliefert. Bleibt aktiv, solange das anhält; endet, wenn wieder Metriken kommen oder der Server ausgeschaltet oder gelöscht wird
CPU saturated	`cpu_saturated` · `CPUSaturated`	Warnung	Hetzners CPU-Wert für den Server liegt 15 Minuten lang über 95 %

server offline löst nie aus für einen Server, den Hetzner als ausgeschaltet meldet, auch wenn er zwischen zwei Synchronisierungen ausgeschaltet wurde, für einen gelöschten Server, solange die Hetzner-API nicht erreichbar ist oder das Token des Projekts ablehnt (dafür gibt es den Token-Alarm), und nicht, wenn Hetzner für alle Teams gleichzeitig still wird.
Auch ein Server, der ausgeschaltet wurde, ohne dass du es getan hast, löst keinen Alarm aus: Hetzner meldet ihn als ausgeschaltet und nennt keinen Grund. Ein Uptime-Check auf seine Adresse überwacht das.

Server: der Agent meldet sich nicht mehr

Für Server, auf denen der Agent läuft. Der Agent sendet alle 30 Sekunden Metriken; diese Regel löst aus, wenn keine mehr ankommen.

Mitteilung	Regel	Schwere	Löst aus, wenn
stopped reporting	`agent_silent` · `AgentSilent`	kritisch	Ein dedizierter Server oder ein Cloud-Server, der nicht mit seiner Hetzner-Ressource verknüpft ist, hat mehr als 5 Minuten lang keine Agent-Metriken gesendet
stopped reporting	`agent_silent` · `AgentSilent`	Warnung	Der Agent eines Cloud-Servers hat mehr als 5 Minuten lang keine Metriken gesendet, während Hetzner die eigenen Metriken des Servers weiter liefert

Der Alarm bleibt aktiv, solange der Server schweigt, und endet mit der ersten neuen Meldung.
Kritisch, wo der Agent das einzige Signal ist: bei einem dedizierten Server oder einem Cloud-Server, der mit einem eigenen Agent-Token statt mit einem Flotten-Token registriert wurde und den Cloud Viewer deshalb nicht seiner Hetzner-Ressource zuordnen kann. Der Alarm kann einen ausgefallenen Server nicht von einem angehaltenen Agent unterscheiden; ein Uptime-Check auf die Adresse des Servers kann das.
Warnung bei einem Cloud-Server, den Hetzner weiter meldet: Der Server läuft, aber bis der Agent sich wieder meldet, gibt es für ihn keine Festplatten-, Speicher- oder Log-Alarme. systemctl status cloudviewer-agent auf dem Server zeigt, warum.
Schweigt auch Hetzner, löst nur server offline aus, nicht beide. Ein Cloud-Server, der nicht mit seiner Hetzner-Ressource verknüpft ist, kann beide bekommen.
Die Regel löst nicht aus für einen Server, der sich noch nie gemeldet hat (Warten auf Agent) oder nur Job-Reports sendet, einen Server außer Dienst, einen Server mit entzogenen Tokens, ein Team ohne Pro oder Team, einen verknüpften Cloud-Server, den Hetzner nicht als laufend meldet (ausgeschaltet, im Rebuild), oder ein Prüfziel.
Verstummen die Agents aller Teams gleichzeitig, liegt die Ursache bei uns, und die Regel hält sich zurück, statt alle zu alarmieren.

Server: der Agent

Für Cloud- und dedizierte Server, auf denen der Agent läuft, aus dem, was er auf dem Host misst.

Mitteilung	Regel	Schwere	Löst aus, wenn
disk space low	`disk_space_low` · `DiskSpaceLow`	Warnung	Ein Dateisystem ist 10 Minuten lang zu mehr als 85 % belegt
disk almost full	`disk_space_critical` · `DiskSpaceCritical`	kritisch	Ein Dateisystem ist 5 Minuten lang zu mehr als 95 % belegt
memory pressure	`memory_pressure` · `MemoryPressure`	Warnung	Die Speichernutzung liegt 10 Minuten lang über 90 %

Die Festplatten-Regeln gelten für jeden Mountpoint einzeln. Dateisysteme im Speicher und Image-Dateisysteme (tmpfs, devtmpfs, ramfs, squashfs, overlay und ähnliche) werden übersprungen.
Die Speichernutzung ist der Gesamtspeicher minus dem verfügbaren Speicher. Page Cache, den der Kernel freigeben kann, zählt also nicht.

Log-Zeilen: der Agent

Aus den journald-Zeilen ab Schweregrad Warning, die der Agent für den Log-Kontext sendet. Es zählen nur Zeilen, die gespeichert wurden, also nach der Grenze von 120 Zeilen pro Minute und Server.

Mitteilung	Regel	Schwere	Löst aus, wenn
critical log lines	`log_critical_lines` · `CriticalLogLine`	Warnung	Mindestens eine Zeile mit Priorität 0–2 (emergency, alert, critical: zum Beispiel ein Kernel-Oops oder ein Out-of-Memory-Kill) in den letzten 10 Minuten. Löst sofort aus und endet 10 Minuten nach der letzten solchen Zeile
error-log burst	`log_error_burst` · `ErrorLogBurst`	Warnung	Mehr als 30 Zeilen mit Priorität 0–3 (error oder schlimmer) innerhalb von 15 Minuten, 5 Minuten lang

Für SSH- und sudo-Zeilen gibt es keine Regel.

Job-Reports

Aus deinen Job-Reports.

Mitteilung	Regel	Schwere	Löst aus, wenn
job failed	`user_job_failed` · `UserJobFailed`	Warnung	Der letzte Report des Jobs hat einen Exit-Code ungleich null, 5 Minuten lang
job stale	`user_job_stale` · `UserJobStale`	Warnung	Der letzte erfolgreiche Durchlauf des Jobs ist älter als das `max_age_seconds`, das er angegeben hat, 5 Minuten lang

Ein Job, der kein max_age_seconds angibt, bekommt nur job failed.
„Veraltet“ zählt ab dem letzten erfolgreichen Durchlauf. Ein Job, der nie erfolgreich war, gilt nie als veraltet.

Uptime-Checks

Aus deinen Uptime-Checks. Ein Check ist nur Nicht erreichbar, wenn beide Netze übereinstimmen. Uneinheitlich und Keine Daten lösen nie einen Alarm aus.

Mitteilung	Regel	Schwere	Löst aus, wenn
unreachable from outside	`check_down` · `CheckDown`	kritisch	Der Check ist 1 Minute lang nicht erreichbar
certificate expiring	`check_cert_expiring` · `CheckCertExpiring`	Warnung	Das Zertifikat ist noch weniger als 14 Tage gültig, 15 Minuten lang
certificate expires imminently	`check_cert_expiring_critical` · `CheckCertExpiringCritical`	kritisch	Das Zertifikat ist noch weniger als 3 Tage gültig, 15 Minuten lang
slower than its budget	`check_slow` · `CheckSlow`	Warnung	Die Antwortzeit aus einem der beiden Netze liegt 10 Minuten lang über dem Antwortzeit-Budget des Checks. Nur für Checks mit Budget, das du im Portal setzt

Die Mitteilung sagt „unreachable“ und nicht „down“, weil sie neben einer Ressource erscheinen kann, die Hetzner weiterhin als laufend meldet.

Unterdrückte Alarme

Solange der kritische Alarm aktiv ist, wird die passende Warnung nicht gesendet.

Solange dieser aktiv ist	unterdrückt er	bei gleichem
`disk_space_critical`	`disk_space_low`	Server und Mountpoint
`check_cert_expiring_critical`	`check_cert_expiring`	Check

Wohin Alarme gehen

Kanal	Schweregrade	Stummgeschaltete Alarme
Die App: Aktive Alarme, Historie, die Ansicht der Ressource	alle	angezeigt, als stumm gekennzeichnet
Push-Mitteilungen	alle; kritische sind auf dem iPhone zeitkritisch	nicht gesendet
E-Mail-Zusammenfassung	Warnung und kritisch oder nur kritisch	nie enthalten
Alarmziele: Webhook, PagerDuty	Warnung und kritisch oder nur kritisch, je Ziel	nie gesendet

Übersicht und Alarmziele tragen nie Alarme mit der Schwere info. Keine der Regeln auf dieser Seite ist info. Übersicht und Ziele einrichten: Alarme dorthin schicken, wo du arbeitest.

Stummschaltungen

Dauer: 1 Stunde, 4 Stunden oder 24 Stunden (die Web-App sagt 1 Tag). Jede App kann eine Stummschaltung mit Stummschaltung aufheben vorzeitig beenden; die Apps für iPhone und Android können sie außerdem mit Stummschaltung verlängern verlängern.
Ein stummgeschalteter Alarm bleibt aktiv. Er bleibt sichtbar, als stumm gekennzeichnet, und wird in der Historie aufgezeichnet.
Jedes Teammitglied kann einen Alarm in den Apps stummschalten.

Historie

Die Alarm-Historie wird 90 Tage aufbewahrt.
Historie in der App zeigt die letzten 30 Tage. Diese Woche N× ausgelöst zählt die letzten 7 Tage.
get_alert_history im Claude-Connector liefert die letzten 7 Tage.

Was keine Regel hat

Load Balancer, Floating IPs, Volumes, Netzwerke und primäre IPs haben keine eigenen Regeln. Um einen Load Balancer oder eine Floating IP zu überwachen, leg im Portal einen Uptime-Check an, der an der Ressource hängt; seine Alarme erscheinen dann dort.
CPU auf dedizierten Servern: Die CPU-Regel liest Hetzners Cloud-Metriken, die dedizierte Server nicht haben.
Load Average, Festplatten-I/O und Netzwerkverkehr: als Chart, ohne Regel.