Changelog

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 Sie ändert sich nichts, solange Sie keinen Agenten verbinden und ihm Schreibrechte erteilen; jeder Schreibvorgang hält fest, wer ihn erlaubt hat, und ein Aufruf, der Ihr 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 Ihnen, 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.