Changelog

Deine Integrationen laufen unverändert weiter, weil API, Webhooks, MCP, Heartbeats sowie JSON, Feeds und Badges deiner Statusseiten nie durch diese Prüfung gehen, und im Browser kann später kurz ein automatischer Check vor dem Laden erscheinen.

Ein Tag, der während oder nach einem Rollout in der Registry verschoben wird, kann so keinen anderen Build mehr auf einen Teil der Flotte bringen, und ein Rollback löst die gewünschte Version genauso auf ihren Digest auf.

Bisher sendeten nur Screenshots und Playwright-Monitore den Header, eigene Request-Header eines Monitors können ihn nicht entfernen, und Keyword- und Antwort-Checks hängen unser SiteMonitorBot-Token zusätzlich an ihren Browser-User-Agent.

Schickt ein überwachter Mail- oder FTP-Server je eine Antwort, die unseren Client gezielt aushebeln soll, trifft sie einen Container, der nur die Zugangsdaten des gerade laufenden Checks kennt, damit deine übrigen Daten und Monitore außer Reichweite bleiben.

Wer darüber hinaus einen Monitor anlegt oder sein Ziel ändert, bekommt 403 mit dem Code targetHostMonitorLimitReached, bestehende Monitore laufen weiter, und der Support hebt die Grenze an, wenn eine Organisation wirklich mehr braucht.

Schickt ein überwachter Server je eine Antwort, die unseren SSH-Client gezielt aushebeln soll, trifft sie einen Container, der nur die Zugangsdaten des gerade laufenden Checks kennt, damit deine übrigen Daten und Monitore außer Reichweite bleiben.

Du bestätigst einen Vorfall direkt am Telefon, ohne die App zu öffnen, und ein verpasster Anruf ist nicht mehr das Ende deiner Kette.

SMS- und Anrufschritte bleiben inaktiv, bis die Nummer per sechsstelligem Code bestätigt ist, und ein Banner beim Login weist darauf hin, damit niemand in seiner ersten Nacht unerreichbar ist.

Warnungen zeigen fehlende Rufnummern, Geräte oder ein leeres Kontingent, bevor es nachts darauf ankommt, und bei einer Vertretung werden jetzt alle Vertretenden gerufen, auch bei laufenden Vorfällen.

Pausierst du einen Heartbeat-Monitor, werden offene Vorfälle ohne Entwarnung geschlossen, damit Wartung an einem Job keine Verwirrung stiftet.

Dein Monitoring-Setup durchläuft denselben Review-Prozess wie deine Infrastruktur, und 429-Antworten tragen Retry-After, sodass der Provider selbst wartet.

Du weißt, dass die Verbindung zu deinem Identity Provider steht, bevor sich jemand aus deinem Team aussperrt.

Ein frisch angelegter Check landet nicht mehr von selbst auf einer Kundenseite, und du stimmst die Seite in Ruhe ab, bevor sie öffentlich wird.

Neu fließen von seven.io Zustellberichte und Anrufstatus zu uns zurück (Nachrichten-ID, Status, Uhrzeit), an seven.io geht nichts Neues, und ein nicht angenommener Anruf wird nach einer Minute genau einmal wiederholt, beschrieben in der Doku zu den Benachrichtigungseinstellungen.

Browser-Push läuft über den Push-Dienst des Browsers, den der Besucher selbst nutzt; er transportiert nur Benachrichtigungen, die für diesen Browser verschlüsselt sind, und kann sie nicht lesen.

Subprozessoren-Liste und AVV-Fassung 3.1 beschreiben UpCloud jetzt richtig, für dich verschiebt sich nichts: Der frühere Eintrag nannte Prüfknoten, Queues und Datenbanken in Finnland, die UpCloud für uns gar nicht betreibt.

Fragt eine Prüfung, wer vor Monaten was geändert hat, steht die Antwort noch in deinem Log und geht als eine CSV-Datei raus.

In unserer Diagnose liegt weniger von deinen Daten, und das Token in einem geteilten Link bleibt bei den Menschen, denen du ihn geschickt hast.

Den Nachweis, wer was getan hat, jede Anmeldung eingeschlossen, gibst du deinem Prüfer als eine Datei, und im Dashboard kann niemand die Einträge dahinter verändern.

Bei großflächigen Hoster-Ausfällen gehen deine Alarme damit pünktlich raus, statt auf einen freien Browser-Platz zu warten.

Deine Prüfungen laufen damit auf schlankeren Images mit weniger Angriffsfläche.

Deine Integrationen und Terraform-Setups reagieren gezielt auf einzelne Fehler, und unser Support findet deinen Aufruf über die Request-ID, die du mitschickst.

So belegst du jedem Kunden, wer einen Monitor, einen Kanal oder ein Wartungsfenster geändert hat und wie er vorher aussah.

Dein Team meldet sich mit den Konten an, die du ohnehin verwaltest, und wer geht, verliert den Zugang, sobald du ihn im Identity-Provider sperrst.

Damit betreust du dänische Kunden in ihrer Sprache, vom Dashboard bis zur Alarm-SMS mitten in der Nacht.

Ein kompromittierter Build-Schritt oder ein einzelner übernommener Server hat damit deutlich weniger Wege, veränderten Code auszuliefern oder an deine Monitoring-Daten zu kommen.

Eingeschleuste Skripte blockiert der Browser, und Passwortraten gegen die Konten deines Teams läuft ins Leere.

Verpasste Prüfminuten und verspätete Alarme zur Release-Zeit gehen damit nicht mehr auf unsere Deploys zurück.

Du siehst, ob ein Anbieter hinter den Seiten deiner Kunden ein Problem hat, bevor du im eigenen Stack suchst.

Du schaltest es für deine Organisation unter Incidents in der Seitenleiste frei, dort als Beta gekennzeichnet, damit bei einem Ausfall zuerst die richtige Person in Bereitschaft Bescheid weiß und nicht deine Kunden.

Deine Kunden lesen jeden Alarm in der Sprache deiner Marke, und eine fehlerhafte Vorlage kostet nie einen Alarm, weil dann unsere Standardvorlage greift.

Fällt eine Datenbank-Replica aus, laufen deine Prüfungen an jedem Standort ungebremst weiter, und die Zahl der Verbindungen bleibt flach, während die Flotte wächst.

An deinen Prüfergebnissen und Blocklisten-Urteilen ändert sich nichts: Konfiguration und Abfragen haben wir vor dem Ausrollen gegen die neue Version geprüft.

Alarme, Berichte und Statusseiten-Mails an deine eigenen Kunden laufen weiter über dein SMTP und dein Branding, Hinweise zwischen dir und Uptimeify hängen nicht mehr davon ab, und die Standardsprache der E-Mails stellst du unter Einstellungen, Whitelabel ein.

Charts, Uptime-Werte und Berichte behalten über die Aggregate ihre volle Historie, das Prüfprotokoll mit Standort und Fehlermeldung reicht dagegen wie bei Websites 24 Stunden zurück.

Solange wir keinem Provider vertrauen, bleibt die Funktion aus; auf der Freigabeseite ist kein Schreibbereich vorausgewählt, und ein freigegebener Agent darf nie mehr als deine aktuelle Rolle.

Monitoring-Daten haben beide nie verarbeitet, und mit dem eigenen Forgejo auf unserer bestehenden EU-Infrastruktur verlassen die letzten zwei US-nahen Dienste unserer Build- und Deploy-Kette die Subprozessoren-Seite.

Blockiert der Bot-Schutz einer Seite unseren Check, bekommen wir kein Ergebnis: diese Zeit galt bisher je nach Prüfstandort als Ausfall oder als störungsfrei, fließt ab sofort nicht mehr in die Uptime-Quote ein und wird getrennt ausgewiesen, damit du siehst, wie lange.

Wir nutzen beide weiter als Rückfall-Resolver, doch sie lösen nur öffentliche Hostnamen nach eigenen Regeln auf, wie Root- und TLD-Nameserver, die wir nie aufgeführt haben, sind also keine Auftragsverarbeiter nach Artikel 28 DSGVO und verlassen die Subprozessoren-Seite.

Gingen mehrere Alarme eines Kontos gleichzeitig raus, kollidierten sie bisher auf dieser einen Verbindung und der unterlegene wurde verworfen, ohne je anzukommen; sie verteilen sich jetzt auf drei, und wer sie alle belegt findet, wird bis zu 90 Sekunden erneut versucht.

Wer einen Kanal auf sofort gestellt hat, bekommt ihn jetzt auch sofort, selbst wenn ein zweiter Kanal desselben Monitors zehn Minuten wartet; das Feld Priorität entfällt, allein danach gestaffelte Kanäle senden dadurch gleichzeitig.

Für dich ändert sich nichts, solange du keinen Agenten verbindest und ihm Schreibrechte erteilst; jeder Schreibvorgang hält fest, wer ihn erlaubt hat, und ein Aufruf, der dein Kontingent auf eine teurere Stufe hebt, wird ohne ausdrückliche Zustimmung abgewiesen.

Scheitert die wöchentliche TXT-Nachprüfung einer eigenen Domain, bleibt sie aktiv und liefert weiterhin Inhalte und Zertifikate aus, und wir sehen uns die Meldung an und melden uns bei dir, statt die Domain im Hintergrund abzuschalten.

Ein einzelner AAAA-Eintrag auf genau einen Host kann nicht ausfallsicher umschalten und hätte die Zertifikatsprüfung beim Umzug auf den falschen Server geschickt, deshalb erreichen Besucher mit IPv6 die Seite bis zur Rückkehr des Eintrags über IPv4.

Statt einer Mail je Website gibt es jetzt eine Sammelmail mit allen Monitor-PDFs im Anhang oder als befristeter Download-Link, und ein Monitor ohne Check in der Periode zeigt einen Strich statt der früheren hundert Prozent Uptime.

Ein Mailserver, den wir nicht betreiben, erreichen oder testen können, konnte nie unsere Maschinerie messen, jeder Versuch hält den Absender fest, das ist also abgelesen und nicht geraten, und ein scheiternder Mailserver bleibt in deiner Historie sichtbar.

Dein Gerät erzeugt bei der Registrierung ein Schlüsselpaar und behält den privaten Teil im Systemspeicher, der Text wird verschlüsselt, bevor der Push uns verlässt, Apple und Google tragen also nicht zu öffnende Bytes, und ohne Schlüssel kommt die allgemeine Zeile.

Google Workspace berührte nie Monitoring-Daten, wohl aber die Korrespondenz selbst, deshalb wird der Inhalt deiner Support-Mails jetzt in Deutschland verarbeitet statt unter dem EU-US Data Privacy Framework, und ein Subprozessor mit US-Bezug fällt weg.

Der Push trägt ein Wecksignal, eine Alarmkennung, die Schwere und ein signiertes Quittungstoken und keine Monitoring-Daten, die Apps sind freiwillig und Alarme erreichen dich weiter per E-Mail, SMS, Anruf und Webhook, und die Widerspruchsfrist beginnt heute.

Übereinstimmung zählt jetzt als Beleg und wird als Zertifikatsproblem mit der Begründung des Browsers abgelegt statt als allgemeiner Ausfall, während eine Zertifikatsklage des Browsers allein weiterhin nichts bestätigt, womit die Load-Balancer- und CDN-Fälle unterdrückt bleiben.

Ein Zwischenspeicher taugt schlecht für etwas, das eine Übergabe überstehen muss, etwa die neue Zustimmungsseite für KI-Assistenten, es wird nichts Neues erhoben oder geteilt, die Werte verfallen nach derselben kurzen Frist, und beides läuft auf Infrastruktur in Deutschland.

Monitore, Vorfälle und Prüfhistorie sind drei getrennte Kästchen, ein abgewähltes hält seinen Bereich dauerhaft draußen, ein unerlaubtes Werkzeug wird dem Assistenten gar nicht erst angeboten, und wer die Seite überspringen will, bekommt eine normgerechte Absage.

Der Browser bekam nur die Restzeit, gemessen wurde er aber am vollen Timeout, weshalb ein Browser, der sein ganzes Fenster erfolglos lud, als beweislos galt, jetzt zählt die Zeit, die er wirklich hatte, und jede fehlgeschlagene Prüfung hinterlässt 90 Tage lang eine Spur.

Die Buchung liegt unter /de/termin mit einem direkten Link unter dem Kalender, falls er nicht lädt, wir erfahren, dass eine Buchung zustande kam und auf welcher Seite der Besuch begann, sonst nichts über dich, und Name, Adresse und Zeit gehen dorthin wie bisher.

Eine von dir geprüfte Domain geht nur dich etwas an und hatte in einem Bericht über besuchte Seiten nichts verloren, deshalb setzen wir die Adresse jetzt selbst, statt sie das Skript lesen zu lassen, und erfassen nur Werkzeugname, Erfolg oder Fehler und die Art der Eingabe.

Der Container enthielt in zwei Jahren zwei Einträge und ist abgeschaltet, das spart je Seite eine Anfrage an einen Google-Host und rund 375 kB Skript, und unsere Messung liegt jetzt im selben Repository, in denselben Reviews und unter denselben Tests wie die Seite.

Du wählst direkt einen Slot und bekommst die Bestätigung ins Postfach statt in eine Rückrufliste, der Dienst ist die Open-Source-Ausgabe von Cal.com auf unserer eigenen Maschine, und weder fremder Buchungsanbieter noch externes Kalender-Widget noch Tracking-Skript sind beteiligt.

Ein Such- oder Filterendpunkt ließ sich bisher nur per POST überwachen, was eine Änderung behauptet, das Körperfeld verhält sich wie bei POST und bleibt verschlüsselt gespeichert, und antwortet ein Ziel mit 405, gibt der Monitor diese Wahrheit unverändert weiter.

Ein Teilen-Link trägt eine zufällige Kennung, ist für Suchmaschinen und Sitemaps gesperrt und nicht durchsuchbar, wir speichern ein Ergebnis nur auf deine Anforderung hin, und ein Vorschlag erscheint nur dort, wo das Ergebnis auf etwas zeigt, das wir wirklich überwachen.

Sie stehen in den Belegen des Vorfalls, in der Alarmmail und in einem neuen Feld blocking_response im Webhook, wir nennen einen bekannten Anbieter wie Cloudflare oder Imperva, wenn die Antwort ihn nennt, und die Header-Liste ist fest und enthält nie Cookies oder Zugangsdaten.

Ein instabiler Monitor erzeugte so rund 110 Vorfälle in acht Stunden, ein Fehlschlag derselben Ursache öffnet jetzt den bestehenden Vorfall erneut und behält dessen Startzeit, und an den Verfügbarkeitswerten ändert sich nichts, weil sie aus Prüfergebnissen kommen.

An jedem Standort bekamen DNS-Dienste und Worker dasselbe Stoppsignal, die Worker aber bis zu eine Minute zum Auslaufen, weshalb den letzten Prüfungen die Namensauflösung fehlte und sie in ihre Zeitgrenze liefen, und die Dienste enden jetzt zuletzt und starten zuerst.

Unsere Routing-Korrektur war echt, aber nicht die Ursache, wir gehen jetzt davon aus, dass SpamCops kostenlose Liste die abfragenden Adressen drosselt, eine Nutzung in unserem Volumen liefe auf eine Lizenz hinaus, und auf Verdacht schalten wir ihn nicht wieder ein.

Eine Resolver-Konfigurationsdatei, die jeder Blacklist-Zone einen direkten Weg gibt, wurde nie wirklich gelesen, monatelange Einträge darin blieben also wirkungslos, und nach dem Laden fiel der Median eines Blacklist-Jobs von rund 22 auf unter 5 Sekunden.

SpamCop antwortete zuverlässig, aber an jedem Standort viel zu langsam und lief damit in unser Zeitbudget je Abfrage, solange der Check pausiert, löst eine nur dort gelistete IP keinen Alarm aus und ein bestehender Eintrag frischt nicht nach, die übrigen Blacklists laufen.

Ein Worker-Host betreibt rund zwanzig Container, ein Wert je Maschine zeigte also Druck, aber nie dessen Ursache, die Metriken je Container gehen an dieselbe selbst gehostete SigNoz-Instanz wie unsere Traces und beschreiben unsere eigenen Prozesse, nichts über deine Ziele.

Diagramme, Verfügbarkeitswerte, Berichte und Statusleisten bleiben über denselben Zeitraum gleich, nur ein Eintrag im Prüflog oder in der Vorfall-Timeline ist nach 48 Stunden eine Zeile je Minute mit Zählern statt einer je Standort, in der API über resolution erkennbar.

Volle Details überstehen einen ganzen Jahreszyklus, doppelt so lang wie das übliche Fenster anderer Werkzeuge, das nächtliche Aggregat entsteht vor jeder Löschung und liegt im Datenexport bei, und ein Vorfall über zwölf Monate verschwindet aus Liste und API, auch ungelöst.

Der alte Pfad behält eine dauerhafte Weiterleitung, UptimeifyToolsBot nennt jetzt eine Adresse, die es wirklich gibt, und hat eine eigene Steckbriefkarte neben SiteMonitorBot und UptimeifyStatusBot, und du kannst eine Domain eingeben und siehst die Antwort deines Servers.

Hat eine Organisation einen eigenen SMTP-Server hinterlegt, geht jede Abo-Mail darüber und sonst über Lettermint, Adresse, Zustimmungszeitpunkt, IP und User-Agent liegen als Einwilligungsnachweis vor, und unbestätigte Anmeldungen verschwinden nach sieben Tagen.

Bisher sahen wir, dass ein Server gesund war und ein Check lief, aber nicht, wofür eine langsame Anfrage ihre Zeit brauchte, die Traces tragen Zeitmessungen und interne Operationsnamen, bleiben 15 Tage liegen, und nichts verlässt unsere Infrastruktur, es kommt kein Anbieter dazu.

Der Planer merkte sich den Zeitpunkt der Auslieferung statt der Minute, zu der ein Check gehörte, weshalb ein wenige Sekunden verspäteter Zyklus den nächsten als noch nicht fällig erscheinen ließ, und er merkt sich jetzt die Minute, womit wieder volle 60 Checks je Stunde laufen.

Screenshots und Playwright-Monitore kamen bisher als anonymes Chrome an und hängen unser Token jetzt an einen normalen Chrome-User-Agent, damit keine WAF eine echte Nutzerreise blockt, und der feste Header ist verlässlicher, weil ein Proxy einen User-Agent umschreiben kann.

An der Funktion ändert sich nichts, eine Adresse lautet <token>@alerts.uptimeify.io, Webhook-Alarmquellen auf unserer Hauptdomain bleiben unberührt, und wer schon eine Adresse auf der alten Domain hat, legt einfach eine neue E-Mail-Alarmquelle an.

Auf unserer öffentlichen Website läuft nur noch die cookiefreie Variante von Leadfeeder, deine IP-Adresse wird gegen eine Firmendatenbank abgeglichen und danach gekürzt oder verworfen, eine Person zu identifizieren ist nicht der Zweck, und in der Anwendung läuft sie nie.

Beide Knoten laufen bei IONOS Cloud in der EU, ihre Adressen stehen schon vor dem ersten Check unter uptimeify.io/ips.txt, damit eine Firewall-Allowlist rechtzeitig nachzieht, und jeder erscheint als eigene Komponente auf unserer Statusseite.

IONOS Cloud füllt dieselbe Rolle wie Hetzner, OVH, netcup und UpCloud, über diese Knoten laufen Monitoring-Daten, also die Prüfergebnisse der von dir überwachten Systeme, und die vollständige Liste steht auf unserer Seite Subprozessoren.

Das präzisiert einen bestehenden Eintrag und verschiebt nichts, es kommt kein neuer Anbieter dazu, die Standorte bleiben Deutschland und Finnland innerhalb der EU, und an der Verarbeitung ändert sich für dich nichts.

Die Quote zählt den Anteil der geplanten Prüfzyklen, den unser Netz tatsächlich gefahren hat, und steht immer neben der Messabdeckung desselben Zeitraums, damit nicht Gemessenes nie still als gesund gilt, daneben stehen Zustellquote und Zeit bis zur ersten Benachrichtigung.

Das korrigiert einen unvollständigen Eintrag und keine geänderte Verarbeitung, seven.io wickelt diese Anrufe ab, seit es Sprachalarme gibt, bleibt ein deutsches Unternehmen und bekommt für einen Anruf dasselbe wie für eine SMS, Rufnummer und Benachrichtigungstext.

Die Zeeg GmbH wickelte über unsere Website gebuchte Demo-, Vertriebs- und Onboarding-Termine ab und verarbeitete Name, E-Mail-Adresse und Termindetails der buchenden Person, dorthin fließen keine Daten mehr, und Zugriff auf dein Konto hatte sie nie.

Das Monitoring pausiert 14 Tage nach der Registrierung, sieben Tage vor der Löschung geht eine Warnmail raus und 30 Tage nach der Pause verschwindet das Konto, sofern kein Zahlungsmittel dazukommt, der Datenexport bleibt erreichbar, und jedes heutige Konto hat volle 14 Tage.

Das Paket enthält Kunden, Monitore, Vorfälle, Wartungsfenster, Kanäle, Statusseiten, Berichte, Abrechnung und Prüfhistorie, jeder Datensatz liegt als JSON und CSV mit Manifest und Zeilenzahlen bei, Zugangsdaten sind geschwärzt, und das ZIP liegt in Deutschland.

Die Flotte umfasst weiterhin sieben europäische Standorte und Checks kommen nicht mehr aus der Schweiz oder aus Tschechien, wer unsere Knoten in einer Firewall freigibt, liest deshalb uptimeify.io/ips.txt neu und prüft Monitore mit entfallenem Länderfilter.

Uptimeify überwacht sich mit Uptimeify, weshalb ein Containertausch bisher einen Vorfall für etwas Geplantes eröffnete, und ein Release erscheint jetzt als geplante Wartung in einem Fenster, das auch bei abgebrochener Pipeline von allein verfällt.

Der Server zieht nur noch ein fertiges, versionsfestes Image und tauscht den Container, was Deploys und Wartungsfenster verkürzt und dasselbe Artefakt auf mehreren Hosts erlaubt, und da Datenbank und Cache eigene Cluster haben, liegen auf dem Anwendungshost keine Kundendaten.

Du bestätigst auf der Claim-Seite einen kurzen Code, der Agent bekommt daraufhin ein lesendes Token im Umfang deiner Organisation oder des einen Kunden, auf den deine Rolle begrenzt ist, kann nie etwas anlegen, ändern oder löschen, und du kannst jederzeit widerrufen.

Unter Einstellungen, Verbundene Anwendungen steht jede Verbindung, etwa Claude am MCP-Endpunkt, ein Entzug trennt sie augenblicklich und verlangt für eine Rückkehr eine neue Freigabe, und jede Verbindung ist lesend und auf dein eigenes Konto begrenzt.

Mit einem Uptimeify-API-Token im Authorization-Header listet ein Agent deine Website-Monitore, liest den Status eines Monitors, listet jüngste Vorfälle, holt Prüfhistorie und Verfügbarkeit, im selben Umfang wie die REST-API und durchgehend nur lesend.

Claude und andere MCP-Clients verbinden sich damit über OAuth 2.1 statt über ein eingefügtes Token, die Verbindung gewährt lesenden Zugriff auf genau das, was dein Konto ohnehin sieht, kann nie etwas anlegen, ändern oder löschen, und läuft auf bestehender Infrastruktur.

Ein Agent findet den Server über die üblichen Well-known-Dokumente, registriert sich anonym, tauscht eine signierte Identitätsaussage gegen ein kurzlebiges opakes Token und kann es widerrufen, wobei diese Token hart auf lesende Anfragen einer expliziten Allowlist begrenzt sind.

easybell stellt SIP-Trunk und Cloud-PBX hinter unserer Firmennummer, Zeeg verarbeitet Name, E-Mail-Adresse und Termindetails der buchenden Person, beide sitzen in Deutschland und arbeiten unter Auftragsverarbeitungsvertrag, und keiner erreicht dein Konto oder Monitoring-Daten.

Ein zustandsloser Endpunkt bietet rund zwanzig anonyme, ausschließlich lesende Werkzeuge für TLS-Prüfung, DNS und Mail-Zustellbarkeit, HTTP-Header und Weiterleitungen, WHOIS, Blacklists und Erreichbarkeit, auffindbar über unsere MCP-Server-Karte und nutzbar ohne Konto.

Beide verbreitern die Infrastruktur, aus der deine Checks laufen, beide sitzen in der EU, und weil ein Check-Knoten die Hostnamen der überwachten Ziele und deren Ergebnisse sieht, steht jeder von beiden jetzt auf unserer Subprozessoren-Seite.

Diese Schicht hing bisher an einer einzigen Instanz und verteilt sich jetzt auf drei Knoten unserer eigenen EU-Infrastruktur, wo Sentinel eigenständig eine Replik befördert und die Worker neu verbindet, sodass Planung und Alarmierung einen Knotenausfall überstehen.

Der Fallback, den unsere lokalen Resolver bei kurzer Sättigung nutzen, liegt damit vollständig in der EU, DNS.SB ist ungefiltert und speichert keine Abfrageprotokolle, DNS4EU bleibt der zweite Fallback, und die Subprozessoren-Seite nennt DNS.SB statt Quad9.

Du kannst eine Alarm-Mail aus jedem Werkzeug an eine eigene Adresse weiterleiten und wir machen daraus einen Vorfall wie aus einem Webhook-Alarm, wobei Lettermint (Niederlande, EU) die Nachricht annimmt und Absender, Betreff und Text über einen authentifizierten Webhook übergibt.

SMS und Anruf sind die letzte Alarmstufe und hingen bisher an einem einzigen Anbieter, deshalb steht LOX24 im kalten Standby, bekommt im Einsatz nichts außer Rufnummer und Benachrichtigungstext und steht jetzt in unserer Subprozessoren-Übersicht.

Jeder Knoten löst über lokale cachende DNS-Resolver auf unserer eigenen Hetzner-Infrastruktur auf, und ein Schwall gleichzeitiger Prüfungen konnte sie kurz scheitern lassen, was eine Prüfung als Ausfall des Ziels las, deshalb haben wir Reserve und Wiederholungsfenster erhöht.

Unsere lokalen Resolver leiteten bisher an einen einzigen Upstream weiter, weshalb dessen Sättigung als Auflösungsfehler und damit als Fehlalarm ankommen konnte, und weil ein Fallback-Resolver die überwachten Hostnamen sehen kann, stehen beide auf unserer Subprozessoren-Seite.

Ein TCP-Port-Monitor prüft aus unserer europäischen Flotte, ob Host und Port innerhalb deines Timeouts eine Verbindung annehmen, optional mit erwartetem Teilstring im Banner, und die Protokoll-Monitore kennen jetzt denselben Erreichbarkeitsmodus ohne Zugangsdaten.

Ubicloud verarbeitet während eines Pipeline-Laufs unseren Quellcode und unsere Build-Secrets und keinerlei Monitoring-Daten von Kunden, und weil die Muttergesellschaft in den USA sitzt, lässt sich ein US-Zugriffsweg nicht ausschließen, abgedeckt über Standardvertragsklauseln.

Managed-Monitore verhalten sich exakt wie bisher, ein Self-Service-Monitor wird dagegen vom Endkunden im Rahmen seines Paketkontingents gepflegt und alarmiert nur dessen Empfänger, und alle bestehenden Monitore wurden als managed eingestuft, es ändert sich also zunächst nichts.

Die Datenbank ist vom Einzelknoten-Container auf einen von Patroni verwalteten PostgreSQL-Cluster umgezogen, der bei Ausfall selbst eine Replik befördert, Bereitstellung und Backups laufen über einen eigenen Infrastruktur-Stack, und alle Daten bleiben in Deutschland.

ICMP-, SMTP-, SSH-, FTP-, IMAP/POP- und DNS-Prüfungen liegen an allen Standorten auf einer Engine, wodurch die Antwortzeiten der Protokoll-Monitore die Verbindung selbst messen statt die DNS-Auflösung, und DNS-Monitore vergleichen auch TXT-Records über 255 Zeichen korrekt.

Wartungsfenster unterdrücken Blacklist-Benachrichtigungen jetzt zuverlässig, Blacklist- und Domain-Ablauf-Alarme erreichen jeden Integrationskanal von Telegram bis PagerDuty, und eine Redirect-Schleife wird vor dem Alarm im echten Browser mit Screenshot belegt.

fastmon erfasst Ladezeit-Telemetrie von Besuchern unserer Web-Anwendung, damit wir Frontend-Geschwindigkeit messen können, wird in Deutschland gehostet, sieht keine überwachten URLs oder Prüfergebnisse und steht in unserer Subprozessoren-Übersicht.

Leadfeeder zeigt uns, welche Unternehmen unsere öffentliche Website besuchen, damit wir Vertriebsinteresse nachverfolgen können, läuft ausschließlich nach ausdrücklicher Cookie-Einwilligung, nie in der Monitoring-Anwendung, und verarbeitet keine Monitoring-Daten.

Die Produktdokumentation ist auf eine eigene Subdomain auf demselben Hetzner-Anwendungsserver in der EU umgezogen, jeder frühere Link unter uptimeify.io/docs führt per dauerhafter Weiterleitung ans Ziel, und an der Datenverarbeitung ändert sich nichts.

Checks liefen bisher nur über IPv4 und nutzen jetzt die Adressfamilie, die eine Seite tatsächlich veröffentlicht, genau wie ein echter Besucher, womit die falschen Verbindungsfehler bei rein über IPv6 erreichbaren Zielen wegfallen.

In unserer Datenschutzerklärung stand Cloudflare als Anbieter für DNS und CDN, was nie zutraf, und der Abschnitt ist in beiden Sprachfassungen entfernt; das Error-Tracking läuft selbst gehostet auf Bugsink in Deutschland und verlässt uns nicht.

Unsere Subprozessoren-Übersicht ist jetzt öffentlich und nennt jeden Dritten, der am Betrieb von Uptimeify beteiligt ist, ob er Monitoring-Daten berührt und wo er sitzt; jede künftige Änderung steht hier und im RSS-Feed.