Plattform-Update August 2026: neun Prüfstandorte und Alarme, die den Blocker benennen

Im August sind 28 Änderungen an der Plattform live gegangen. Zwei davon verlangen etwas von dir: Die Flotte ist auf neun Prüfstandorte gewachsen, und wer unsere IP-Adressen in einer Firewall führt, liest die Liste neu ein. Wer Alarme per E-Mail einliefert, holt sich einmalig eine Adresse auf der neuen Domain. Der Rest ist zum Mitnehmen: Alarme, die den Blocker beim Namen nennen, ein Header, mit dem du uns ohne IP-Pflege freischaltest, Abos für deine Status-Seiten und eine eigene Verfügbarkeitszahl, die wir messen statt zu behaupten.

Was du tun musst: die IP-Liste und eine Adresse

Seit dem 2. August gehören Berlin und Logroño zur Prüfflotte. Beide laufen auf IONOS Cloud und stehen innerhalb der EU. Die vier neuen IPv4-Adressen und ihre IPv6-Gegenstücke standen in uptimeify.io/ips.txt, bevor die Knoten Verkehr übernommen haben. Genau dafür ist der Vorlauf da: Eine Adresse, die deine Firewall nicht kennt, sieht aus wie ein Ausfall, der keiner ist.

Die zweite Sache betrifft nur E-Mail-Alarmquellen. Die Adresse, an die du Alarm-Mails aus anderen Werkzeugen weiterleitest, liegt jetzt auf alerts.uptimeify.io statt auf ingest.uptimeify.io. An der Funktion ändert das nichts, der Name sagt nur, was dort passiert. Webhook-Alarmquellen aus Zabbix, Datadog, Grafana, Prometheus Alertmanager oder Sentry sind nicht betroffen.

Spanien ist neu in der Länderliste. Bisher starteten Checks aus Deutschland, Finnland, Frankreich, Italien und Polen. Monitore, die ihre Prüfungen auf bestimmte Länder beschränken, können Spanien jetzt auswählen, was vor allem für iberische Endpunkte zählt: Der nächstgelegene Knoten war bis dahin Paris oder Mailand. Beide neuen Standorte erscheinen als eigene Komponenten auf unserer Statusseite, mit eigener Verfügbarkeit und eigener Messabdeckung. Am Speicherort deiner Daten ändert sich nichts, die Plattform bleibt in Deutschland gehostet.

Alarme sagen jetzt, wer die Anfrage abgelehnt hat

Ein 503 sagt dir, dass etwas die Anfrage abgelehnt hat. Er sagt dir nicht, ob deinkunde.com ausgefallen ist oder ob eine Web Application Firewall unseren Check aussortiert hat, bevor er den Server erreicht hat. Bisher haben wir nur den Statuscode gespeichert, und diese Frage ließ sich ohne einen Blick in unsere Logs nicht beantworten.

Seit dem 20. August behält ein Check, der mit 403, 406, 429 oder 503 beantwortet wird, die Antwort-Header, die den Absender ausweisen: server, cf-ray, x-sucuri-id, x-iinfo, retry-after und eine Handvoll Verwandte. Nennen diese Header einen bekannten Anbieter, nennen wir ihn beim Namen, etwa Cloudflare, Sucuri, Imperva, DataDome, Akamai oder Fastly. Nennt die Antwort niemanden, schreiben wir nichts hin, statt zu raten.

Du findest das an drei Stellen: im Beleg-Bereich des Vorfalls, als zusätzlichen Block in der Alarm-Mail und als neues Feld blocking_response innerhalb von error_details im JSON-Webhook. Bestehende Webhook-Felder bleiben unverändert, an deinen Integrationen bricht nichts.

Was wir bewusst nicht speichern: Die Header-Liste ist eine feste Allowlist. Cookies sowie Authorization- und Authentication-Header werden nie gespeichert und nie weitergegeben, und jeder Wert wird gekürzt. Eine Antwort, die wir aufzeichnen, ist eine Antwort, die wir weiterreichen können, also trägt sie nur das, was einen Block ausweist.

Jeder Check identifiziert sich, auch der Browser

Unsere einfachen Checks für HTTP, SSL und Weiterleitungen tragen seit jeher SiteMonitorBot im User-Agent. Die browserbasierten Checks taten das nicht: Screenshots und Playwright-Monitore kamen als anonymes Chrome an und waren in deinem Access-Log von einem gewöhnlichen Besucher nicht zu unterscheiden. Das ist seit dem 4. August erledigt.

Der User-Agent der browserbasierten Checks trägt unser Kürzel jetzt am Ende des normalen Chrome-Strings. Wir hängen an, statt zu ersetzen, und zwar mit Absicht: Ein Playwright-Monitor läuft eine echte Nutzerstrecke ab, ein Login, einen Checkout, und viele WAFs blocken einen nackten Bot-User-Agent sofort. Dann würden wir einen Ausfall melden, den deine Besucher nicht erleben.

Verlässlicher als der User-Agent ist der zweite Weg. Jeder Check sendet zusätzlich den Header X-Uptimeify-Monitor: 1. Ein CDN oder Reverse Proxy kann einen User-Agent umschreiben, einen eigenen Header eher nicht. Der Wert ist konstant und enthält nie eine Monitor-, Kunden- oder Kontokennung. Filterst du doch auf den User-Agent, filtere auf die Teilzeichenkette SiteMonitorBot und nie auf den vollen String, denn dort steht eine Chrome-Version, die sich mit jedem Browser-Update ändert.

Dazu ist unsere Bot-Seite auf uptimeify.io/robot umgezogen und neu gebaut. Jeder unserer drei Clients hat dort eine Spezifikationskarte mit User-Agent, Zusatz-Header, Frequenz und Quelladressen, die Adressliste wird live aus der aktiven Flotte erzeugt statt von Hand gepflegt, und eine Tabelle übersetzt, was du im Log siehst, in das, was zu tun ist. Neu dokumentiert ist UptimeifyToolsBot, der Client hinter unseren kostenlosen Tools und den anonymen Prüfungen unseres MCP-Servers. Auf derselben Seite kannst du eine Domain eingeben und sie mit dem echten SiteMonitorBot-User-Agent abrufen lassen, um zu sehen, was dein Server uns antwortet. Wenn eine Bot-Regel unser Monitoring blockiert, siehst du es dort, bevor es als Ausfall erscheint, den es nicht gibt.

Ein instabiler Monitor ergibt einen Vorfall, nicht dutzende

Springt eine Seite zwischen gesund und fehlerhaft hin und her, hat unsere Flap-Erkennung diesen Zustand schon immer erkannt und aufgehört, für jeden Ausschlag zu alarmieren. Was sie nicht gestoppt hat, war der Vorfall-Datensatz selbst: Jeder Ausschlag öffnete einen neuen Vorfall, der sich löste, der wieder aufmachte. Ein Monitor in diesem Zustand hat in acht Stunden rund 110 Vorfälle erzeugt.

Seit dem 20. August öffnet ein erneuter Fehler derselben Ursache den bestehenden Vorfall wieder, solange der Monitor flappt. Der Vorfall bleibt offen, solange die Episode dauert, und behält seine ursprüngliche Startzeit. Seine Dauer ist damit die Dauer der Instabilität. Eine andere Ursache, etwa ein Zertifikatsproblem während einer Ausfallepisode, bekommt weiterhin einen eigenen Vorfall.

An deinen Verfügbarkeitswerten ändert das nichts. Uptime wird aus den Prüfergebnissen berechnet, nie aus der Vorfall-Liste. Ein zusammengeführter Vorfall bewegt keinen Prozentpunkt auf einem Report oder einer Status-Seite.

Im selben Zug haben wir eine Lücke bei kurzen Intervallen geschlossen. Ping- und IMAP/POP-Monitore mit einem Intervall von einer Minute haben rund 12 Prozent ihrer Checks verpasst, und zwar nicht zufällig: immer in denselben zwölf Minuten jeder Stunde, an allen neun Standorten gleichzeitig. Der Scheduler hatte pro Monitor den Zeitpunkt der letzten Ausführung gespeichert. Startete ein Zyklus ein paar Sekunden nach der vollen Minute, war der letzte Check formal noch keine Minute alt, und der Monitor galt als noch nicht fällig. Jetzt merkt sich der Scheduler die Minute, zu der ein Check gehört, und diese Regel gilt für alle Monitortypen. Wer auf einem Ein-Minuten-Intervall prüft, bekommt volle 60 Zyklen pro Stunde. Die fehlenden Checks der Vergangenheit sind Lücken und lassen sich nicht nachtragen.

Status-Seiten mit Abo: E-Mail und RSS

Öffentliche Status-Seiten bieten seit dem 8. August Abos per E-Mail und per RSS an. E-Mail-Abos laufen im Double-Opt-in: Eine Adresse bekommt nichts, bevor sie aus der Bestätigungsmail heraus bestätigt wurde.

Hat eine Organisation einen eigenen SMTP-Server hinterlegt, geht jede Abo-Mail darüber hinaus. Ohne eigenen Server läuft die Zustellung über Lettermint, unseren bestehenden E-Mail-Subprozessor, ein neuer Anbieter kommt nicht hinzu. Als Einwilligungsnachweis speichern wir die Adresse, den Zeitpunkt, die IP-Adresse und den User-Agent aus der Anmeldung. Nicht bestätigte Anmeldungen werden nach sieben Tagen gelöscht. Wer die Funktion nicht will, schaltet sie je Status-Seite in den Einstellungen ab.

Für eine Agentur ist das der Unterschied zwischen einer Seite, die der Kunde aufrufen muss, und einer Nachricht, die ihn erreicht, bevor er zum Telefon greift. Der Absender ist dabei deiner.

Wir veröffentlichen unsere eigene Verfügbarkeit

Wir bitten dich, einer Zahl zu vertrauen, die wir über deine Systeme erzeugen. Dann ist es nur fair, die Zahl über unsere eigenen genauso zu messen und sichtbar zu machen, ohne dass du danach fragen musst.

Gemessen wird die Check-Zustellung: der Anteil der Prüfzyklen, die unser Netz ausführen sollte und tatsächlich ausgeführt hat. Ein Zyklus zählt als zugestellt, wenn mindestens einer unserer Standorte ihn gefahren hat. Nur ein Zyklus, der nirgends stattgefunden hat, zieht ab. Angekündigte Wartungsfenster sind nicht ausgenommen: Ein Wartungsfenster unterdrückt die Alarmierung, nicht die Planung, deine Checks laufen währenddessen wirklich.

Daneben steht eine zweite Zahl, die Messabdeckung. Sie sagt, wie viel des Zeitraums wir überhaupt belegen können. Minuten, in denen die Aufzeichnung stillstand oder eine Aggregation nicht durchlief, gelten nie als gesund und verschwinden auch nicht still, sie senken die Abdeckung. Was sie nicht sind, ist Ausfallzeit. "Wir waren nicht verfügbar" und "wir konnten nicht messen" sind verschiedene Aussagen. Für die konservative Lesart multiplizierst du beide Werte.

Für die Alarmierung veröffentlichen wir den Anteil der Zustellversuche, die am Ende durchkamen, und die p90-Zeit vom Öffnen eines Vorfalls bis zur ersten Benachrichtigung, die unsere Systeme verlassen hat. Zustellungen, die am Ziel scheitern, weil der Endpunkt weg ist, die Zugangsdaten widerrufen wurden oder dein Dienst uns ausbremst, zählen als Endpunkt-Fehler und stehen neben der Zahl statt in ihr. Alles, was wir nicht sicher der Gegenseite zuordnen können, zählt gegen uns.

Die aktuellen Werte über 90 Tage, der Zustand jeder Komponente und die Monatssummen stehen auf unserer öffentlichen Statusseite und maschinenlesbar unter uptimeify.io/api/service-status, ohne Anmeldung und ohne Kundendaten. Ein abgeschlossener Monat wird eingefroren, jeder Eintrag ist an den vorherigen hash-verkettet. Speicherst du die heutige Antwort und liest ein vergangener Monat später anders, sagt es dir der Hash. Die alte Verfügbarkeitszahl auf der Landingpage stammte aus keiner dieser Messungen. Wir haben sie entfernt und bringen sie zurück, wenn die gemessene Reihe lang genug ist, um dahinterzustehen.

Wie lange deine Historie bleibt

Ein Monitor, der jede Minute von mehreren Standorten prüft, schreibt eine Zeile pro Standort und Minute. Vollständig aufbewahrt ist das mit Abstand das Größte, was wir speichern, und es wächst mit jedem Monitor. Gelesen wird es fast nie: Ein Chart, ein Uptime-Wert, ein Report und ein Statusbalken fragen nach einer Minute, einem Tag oder einem Monat, nicht nach einer einzelnen Zeile.

Deshalb werden die Zeilen jetzt verdichtet. Jeder Check erzeugt dieselben Daten und denselben Alarm, wird zu Aggregaten pro Minute, pro 15 Minuten und pro Tag zusammengefasst, und die Einzelzeilen fallen nach 48 Stunden weg. Die Aggregate bleiben so lange erhalten, wie es dein Paket vorsieht. Dieselben Charts, dieselbe Uptime, dieselben Monats- und Jahreswerte über denselben Zeitraum wie zuvor.

Was sich ändert, ist die Auflösung zweier Detailansichten jenseits von 48 Stunden. Im Prüflog und in der Vorfall-Zeitleiste steht ein älterer Eintrag als eine Zeile pro Minute statt einer Zeile pro Standort: wie viele Standorte geprüft haben und wie viele davon fehlgeschlagen sind. Beide Ansichten markieren solche Einträge, und die API liefert ein Feld resolution mit raw oder 1min. Innerhalb von 48 Stunden bleibt alles wie bisher, einschließlich der Belege zu einem Vorfall, die beim Anlegen kopiert werden und die Rohzeilen überleben.

Für das Incident Management gilt eine eigene Frist: zwölf Monate volles Detail, danach 24 Monate als Tagesaggregat pro Team und Schweregrad mit Anzahl, Zeit bis zur Bestätigung und Zeit bis zur Lösung. Zwölf Monate sind doppelt so viel, wie die meisten Werkzeuge dieser Art standardmäßig offen halten, und decken einen vollen Jahreszyklus ab. Zwei Konsequenzen gehören dazu: Ein Vorfall jenseits von zwölf Monaten erscheint nicht mehr in Liste und API, auch wenn er nie gelöst wurde, und ein Report, der weiter zurückreicht, zeigt Mittelwerte statt eines p95.

Nebenbei sind die Lesepfade schneller geworden, weil ein Monat Chart-Daten jetzt ein paar tausend Aggregatzeilen sind statt eines vollständigen Scans. Die Detailseite ging von 4,6 auf 1,2 Sekunden im p95, das Löschen eines Monitors von 27 auf 0,3 Sekunden.

Was sich sonst geändert hat

• HTTP QUERY für Monitore. Manche Endpunkte antworten nur richtig, wenn die Anfrage einen Body trägt: eine Suche, ein Filter, eine Abfrage im GraphQL-Stil. Bisher blieb dafür nur POST, was behauptet, die Anfrage verändere etwas. QUERY steht jetzt in der Methodenliste jedes HTTP-Monitors, und die API nimmt httpMethod: QUERY beim Anlegen und Ändern an. Antwortet ein Server mit 405, ist das die Wahrheit über den Endpunkt, und der Monitor meldet sie wie jeden anderen unerwarteten Status.
• Ergebnisse aus den kostenlosen Tools teilen. Nach einer Prüfung erzeugst du einen dauerhaften Link auf genau dieses Ergebnis und schickst ihn weiter, was Agenturen mit einem Kunden ohnehin tun. Der Link ist ungelistet, trägt eine zufällige Kennung, ist von Suchmaschinen und Sitemaps ausgeschlossen und läuft nach 30 Tagen ab. Gespeichert wird ein Ergebnis nur, wenn du einen Link anforderst.
• Nachgelagerter Vorschlag statt Dauerwerbung. Wo ein Tool-Ergebnis auf etwas zeigt, das wir wirklich überwachen können, sagt die Seite das in den Worten des Ergebnisses: ein Zertifikat, das in 23 Tagen abläuft, eine DMARC-Richtlinie auf none, eine IP auf einer Blockliste. Wo es auf nichts zeigt, steht dort nichts.
• Domains aus den Tools erreichen unsere Analytics nicht mehr. Mehrere Tools tragen die Eingabe in der Seitenadresse, damit ein Ergebnis als Link teilbar bleibt. Diese Adresse wird jetzt am Fragezeichen abgeschnitten, bevor sie an die Analyse geht. Was wir zu einer Tool-Nutzung festhalten, ist der Name des Tools, ob ein Ergebnis oder ein Fehler kam und ob die Eingabe eine Domain, Text oder eine Datei war.
• Google Tag Manager ist von unseren Seiten verschwunden. Analytics und unser Lead-Werkzeug werden jetzt direkt aus unserem eigenen Code geladen. Nichts kommt hinzu, nichts Neues wird erhoben. Auf jeder Seite ist das eine Anfrage weniger an einen Google-Host und rund 375 kB Skript, das nicht mehr ankommen muss. Deine Einwilligung steuert weiterhin alles, Standard ist nein.
• Termine laufen auf unserer eigenen Seite. Die Terminbuchung liegt seit dem 28. August unter uptimeify.io/de/termin, der Kalender ist dort eingebettet statt in einer zweiten Domain. Dahinter läuft weiterhin Cal.com in der Open-Source-Fassung auf einer Maschine, die wir selbst in der EU betreiben.

Was im Maschinenraum passiert ist

Der Rest des Monats ist Infrastruktur. Nichts davon musst du bedienen, alles davon merkst du daran, dass nichts passiert.

• Anwendungs-Traces auf eigener Infrastruktur. Plattform und Check-Worker senden jetzt Traces, also die Zeitachse einer Anfrage durch Anwendung, Datenbank und Queue, an eine SigNoz-Instanz, die wir selbst hosten. Kein zusätzlicher Anbieter, kein Subprozessor, keine Telemetrie, die unsere Infrastruktur verlässt. Die Traces tragen Zeitmessungen und interne Operationsnamen und werden nach 15 Tagen gelöscht.
• Metriken pro Container. Ein Worker-Host betreibt rund zwanzig Container, und seine CPU- und Speicherwerte waren bisher eine Summe. Jetzt melden die Hosts Speicher und CPU je Container. Damit wird aus einer Kapazitätsentscheidung eine gemessene statt einer geschätzten.
• Resolver bleiben beim Deploy stehen. Jeder Prüfstandort betreibt zwei lokale DNS-Resolver neben den Workern. Beim Ausrollen einer neuen Worker-Version wurden alle Container gleichzeitig gestoppt, die Worker bekamen bis zu einer Minute zum Leerlaufen, die Resolver nicht. Ergebnis war ein kurzer, selbst verursachter Fehlerschub am Ende jedes Deploys. Die Resolver fahren jetzt erst nach den Workern herunter und vor ihnen wieder hoch, geprüft gegen die Container-Laufzeit statt angenommen.
• Blocklisten-Prüfungen rund viermal schneller. Eine Konfigurationsdatei, die jeder Blocklisten-Zone einen direkten Auflösungsweg gibt, wurde von unseren Resolvern nie gelesen. Seit sie tatsächlich geladen wird, fiel die Laufzeit eines Blocklisten-Jobs im Median von rund 22 auf unter 5 Sekunden.
• SpamCop bleibt vorerst pausiert. Wir hatten die Prüfung wieder aktiviert und uns dabei in der Ursache geirrt, wie hier nachzulesen ist: Die öffentliche Liste begrenzt, wie viel eine einzelne abfragende Adresse anfragen darf, und genau so fragen wir von jedem Standort aus. Eine IP, die ausschließlich bei SpamCop gelistet ist, löst deshalb keinen neuen Alarm aus. Die rund vierzig anderen Blocklisten sind davon unberührt.

Neue und gewechselte Subprozessoren

Fünf Einträge haben sich im August bewegt. Die vollständige Liste steht auf der Subprozessoren-Seite.

Zwei Anmerkungen dazu. Bei netcup und UpCloud ist nichts umgezogen, die Beschreibung war unvollständig: Dort laufen neben Prüfknoten auch Queues und Datenbanken, die Standorte bleiben Deutschland und Finnland. Bei seven.io stand nur die SMS-Zustellung im Eintrag, obwohl der Anbieter unsere Sprachanrufe seit jeher stellt. Übergeben werden dabei die Rufnummer des Empfängers und der Inhalt der Benachrichtigung, für den Anruf wie für die SMS.

Außerdem läuft Leadfeeder seit dem 3. August nur noch in der cookiefreien Variante. Sie setzt keine Cookies und greift auf nichts auf deinem Gerät zu. Deine IP-Adresse wird gegen eine Firmendatenbank abgeglichen und danach gekürzt oder verworfen. Das läuft ausschließlich auf unserer öffentlichen Website und nie in der Monitoring-Anwendung.

Was als Nächstes ansteht

Eine Einschränkung nennen wir lieber, als sie zu verschweigen: Ein Zyklus, den wir verpasst haben, kann in unserer eigenen Verfügbarkeitszahl als zugestellt erscheinen, wenn ein von dir per API ausgelöster Check im selben Fenster landet. Wir kennzeichnen die Herkunft eines Checks an der Quelle, um diesen Fall zu schließen. Bestätigungs-Checks von einem zweiten Standort haben diesen Effekt nicht, sie erzeugen keinen zusätzlichen Zyklus.

Was sonst geplant ist, steht auf der Roadmap. Termine nennen wir dort, wo sie halten.

Alle Änderungen dieses Monats mit Datum und vollem Wortlaut findest du im Changelog. Warum der Standort der Prüfknoten für europäische Kunden mehr ist als eine Detailfrage, steht in unserem Beitrag zu Polling-Nodes in der EU.