Changelog

Als wir die E-Mail-basierte Alarmquelle eingeführt haben, hiess es, die Adresse für weitergeleitete Alarm-Mails liege auf ingest.uptimeify.io. Sie liegt jetzt stattdessen auf alerts.uptimeify.io — eine Adresse sieht also so aus: <token>@alerts.uptimeify.io.

An der Funktionsweise ändert sich nichts: Du leitest eine Alarm-Mail aus einem beliebigen Werkzeug weiter, Lettermint (Niederlande, EU) nimmt sie entgegen und reicht Absender, Betreff und Text über einen authentifizierten Webhook an unsere Plattform, und daraus entsteht ein Vorfall — genau wie aus einem Webhook-Alarm. Lettermints Rolle und sein Eintrag in unserer Subprozessoren-Übersicht bleiben unverändert.

Nur der Name ist anders, und er ist der klarere: alerts. sagt, was dorthin geht.

Webhook-Alarmquellen sind nicht betroffen. Zabbix, Datadog, Grafana, Prometheus Alertmanager, Sentry und eigene Webhooks senden weiterhin an https://uptimeify.io/api/im/ingest/<token> auf unserer Hauptdomain. Auf deiner Seite ist nichts zu tun.

Falls du bereits eine Eingangsadresse auf der alten Domain hast, lege eine neue E-Mail-Alarmquelle an, um eine Adresse auf der neuen Domain zu erhalten.

Auf unserer öffentlichen Website nutzen wir ab sofort ausschließlich die cookiefreie Variante von Leadfeeder (Dealfront Group GmbH, Deutschland). Es werden keine Cookies gesetzt und es wird nicht auf Informationen auf deinem Endgerät zugegriffen, eine Cookie-Einwilligung ist dafür also nicht mehr nötig. Deine IP-Adresse wird gegen eine Unternehmensdatenbank abgeglichen, um das hinter einem Besuch stehende Unternehmen zu bestimmen, und anschließend gekürzt oder verworfen — die Identifikation einzelner Personen ist nicht Zweck der Verarbeitung.

Damit ändert sich die Rechtsgrundlage: Die Verarbeitung stützt sich jetzt auf unser berechtigtes Interesse nach Art. 6 Abs. 1 lit. f DSGVO statt auf eine Einwilligung, und du kannst ihr jederzeit nach Art. 21 DSGVO widersprechen. Sie läuft weiterhin nur auf unserer öffentlichen Website, niemals innerhalb der Monitoring-Anwendung, und verarbeitet weiterhin keine Monitoring-Daten.

Die Subprozessor-Übersicht und unsere Datenschutzerklärung wurden entsprechend aktualisiert.

Wir nehmen zwei Prüfstandorte in unsere europäische Flotte auf: Berlin (DE) und Logroño (ES). Beide laufen bei IONOS Cloud, das als Subprozessor für Check-Knoten-Infrastruktur bereits gelistet ist, und beide liegen innerhalb der EU. Die Flotte wächst damit von sieben auf neun Standorte.

Spanien ist neu in der Flotte. Bisher starteten unsere Checks aus Deutschland, Finnland, Frankreich, Italien und Polen; Monitore, die Prüfungen auf bestimmte Länder beschränken, können jetzt auch Spanien wählen. Das zählt vor allem für iberische Endpunkte, deren nächster Knoten zuvor Paris oder Mailand war.

Wenn du unsere Prüfknoten in einer Firewall freischaltest, werde jetzt tätig. Die vier neuen IPv4-Adressen und ihre IPv6-Gegenstücke stehen bereits in uptimeify.io/ips.txt, bewusst bevor die Knoten Verkehr aufnehmen — diese Datei ist die maßgebliche Liste, und die Adressen vor dem ersten Check einzutragen ist genau das, was verhindert, dass ein neuer Standort bei dir wie ein Ausfall aussieht. Wenn du eine Kopie von Hand pflegst, lies sie jetzt neu ein.

Beide Standorte erscheinen auf unserer Statusseite als eigene Komponenten, mit eigener Verfügbarkeit und eigener Messabdeckung, sobald sie Checks ausführen.

Am Speicherort und an der Verarbeitung deiner Daten ändert sich nichts: Die Plattform bleibt in Deutschland gehostet, ein neuer Subprozessor ist nicht beteiligt.

Wir haben IONOS SE (IONOS Cloud) als Subprozessor in unsere Liste aufgenommen. IONOS stellt Server-Infrastruktur für Monitoring-Check-Knoten bereit — dieselbe Rolle, die Hetzner, OVH, netcup und UpCloud bereits erfüllen.

Der Standort ist Deutschland und damit innerhalb der EU. Über diese Knoten laufen Monitoring-Daten, also die Prüfergebnisse deiner überwachten Systeme; Inhalte deiner Endkunden werden dort nicht gespeichert.

Die vollständige Liste findest du auf der Seite Subprozessoren.

Wir haben die Rollenbeschreibung von netcup GmbH und UpCloud Ltd in unserer Subprozessoren-Liste präzisiert. Beide stellen nicht nur Monitoring-Check-Knoten bereit, sondern betreiben auch Redis-Job-Queues und Datenbanken für uns.

Das ist eine Klarstellung dessen, was dort tatsächlich läuft, keine Verlagerung: es kommt kein neuer Anbieter hinzu, und die Standorte bleiben unverändert — netcup in Deutschland, UpCloud in Finnland, beide innerhalb der EU. Für dich ändert sich dadurch nichts an der Verarbeitung; die Angabe ist jetzt nur vollständiger.

Die vollständige Liste findest du auf der Seite Subprozessoren.

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

Was wir messen. Die Kennzahl ist die Check-Auslieferung: der Anteil der Prüfzyklen, die unser Prüfnetz ausführen sollte und tatsächlich ausgeführt hat. Jeder Monitor ist einmal pro Prüfintervall fällig, das ist ein Zyklus. Ein Zyklus gilt als ausgeliefert, sobald mindestens einer unserer Standorte ihn tatsächlich ausgeführt hat; abgezogen wird nur ein Zyklus, der nirgends eine Prüfung erzeugt hat. Ganze Zahlen, keine Anteile, keine Mittelwerte — dieselbe Form wie die Verfügbarkeit, die wir für deine eigenen Monitore berechnen: Sie zählt beobachtete Zeit und sinkt nur bei einem echten Fehler. Das ist die Leistung, die wir dir schulden, also zählen wir sie. Nicht, ob unsere Marketing-Seite eine Anfrage beantwortet hat.

Worauf wir dabei bewusst verzichten. Fällt einer unserer Standorte aus, verteilt der Scheduler dessen Arbeit auf die übrigen, und die Zyklen laufen weiter — diese Zahl bleibt also auch während eines Standortausfalls nahe 100 %. Das ist der richtige Tausch. Der Verlust eines Standorts ist ein reales Ereignis und wird direkt veröffentlicht, pro Standort: Jeder Prüfstandort ist auf der Statusseite eine eigene Komponente, mit eigener Verfügbarkeit und eigener Messabdeckung. Einen Ausfall aus Arithmetik abzuleiten, ist das schwächere Signal; ihn zu messen, das stärkere.

Zwei Zahlen, nicht eine. Die Verfügbarkeit wird über die Minuten gemessen, die wir belegen können. Daneben veröffentlichen wir die Messabdeckung: wie viel des Zeitraums das tatsächlich war. Wenn die Aufzeichnung aussetzt, eine Aggregation nicht durchläuft oder eine Komponente keinen Zustand meldet, gelten diese Minuten nie als gesund und werden nie stillschweigend fallen gelassen — sie senken die Abdeckung. Was sie nicht sind: Ausfallzeit. „Wir waren nicht verfügbar" und „wir konnten nicht messen" sind zwei verschiedene Aussagen. Die zweite als die erste zu melden, würde einen Ausfall veröffentlichen, den es nicht gab, und die Kennzahl zu einem Maß für die Zuverlässigkeit unseres eigenen Recorders machen. Beide Werte stehen immer zusammen, auch wenn die Abdeckung schlecht aussieht; multipliziere sie für die konservative Lesart.

Alarm-Zustellung, in zwei Zahlen. Neben der Check-Auslieferung veröffentlichen wir, wie sich unsere Alarmierung selbst geschlagen hat: den Anteil der versuchten Zustellungen, die am Ende angekommen sind, und die p90-Zeit von der Eröffnung eines Vorfalls bis zur ersten Benachrichtigung, die unsere Systeme tatsächlich verlassen hat. Zwei Zahlen, weil eine beide Fragen nicht beantworten kann — und eine Zustellung, die zweimal scheiterte und beim dritten Mal klappte, zählt einmal, als zugestellt, statt dem Versuch angelastet zu werden, der sie gerettet hat.

Wessen Fehler es war. Die Zustellquote zählt die Fehler, die uns gehören. Kommt ein Alarm nicht an, weil das Ziel gelöscht wurde, weil die Zugangsdaten widerrufen sind, weil dein Dienst uns drosselt oder sein Host gar nicht erreichbar ist, dann ist das ein Fehler dieses Ziels. Ihn unserer Alarmierung anzulasten, würde die Kennzahl zu einem Maß für die Webhooks aller Kunden machen statt für unsere Maschinerie. Versteckt werden diese Fälle trotzdem nicht: Sie werden gezählt und neben der Quote als Ausfälle beim Empfänger veröffentlicht, sodass beide Zahlen zusammen weiterhin jeden Alarm erklären, der nicht ankam. Was wir nicht sicher der Gegenseite zuordnen können, zählt gegen uns — die umgekehrte Regel würde die Zahl jedes Mal verbessern, wenn wir eine neue Art zu scheitern finden.

Nichts reicht hinter den Tag zurück, an dem wir zu messen begonnen haben. Unsere Benachrichtigungsdaten reichen deutlich weiter zurück als unsere eigene Messung. Die Alarm-Kennzahlen nutzen diese Historie nicht: Sie beginnen dort, wo das „Messung seit"-Datum auf der Statusseite beginnt, wie alles andere darauf. Eine Weile werden beide Alarmzahlen deshalb sagen, dass es noch zu früh ist, statt einen Wert zu zeigen — und das ist genau richtig so.

Eine Zahl erscheint, wenn sie etwas bedeutet. Die Check-Auslieferung veröffentlichen wir, sobald die Messreihe eine Stunde abdeckt, die Alarm-Kennzahlen, sobald mindestens 20 Ereignisse dahinterstehen. Darunter nennt die Seite die Schwelle, statt eine Zahl zu drucken: Auf kurzer Strecke verschiebt eine einzige von unserem Scheduler verpasste Minute den Wert um einen ganzen Prozentpunkt — das sagt mehr über die Länge der Messreihe als über das Prüfnetz —, und ein Prozentwert über eine Handvoll Ereignisse ist Rauschen im Gewand von Genauigkeit. Sichtbar bleibt in beiden Fällen das Datum des Messbeginns, die Messabdeckung und die Stichprobengröße: die Dinge, die das Fehlen erklären.

Angekündigte Wartung wird nicht herausgerechnet. Ein Wartungsfenster in Uptimeify unterdrückt die Alarmierung, nicht die Planung — deine Checks laufen währenddessen wirklich. Also zählen sie in unserer Kennzahl wie jeder andere Check, statt herausgeschnitten zu werden, wie es bei Verfügbarkeitszahlen sonst üblich ist.

Wo du das findest. Der aktuelle Wert über die gleitenden 90 Tage, der Zustand jeder veröffentlichten Komponente und die Monatswerte dahinter stehen auf unserer öffentlichen Statusseite und maschinenlesbar unter uptimeify.io/api/service-status — ohne Anmeldung, ohne Kundendaten. Schließt ein Monat, werden seine Werte eingefroren: Der Datensatz lässt sich nur noch ergänzen, und jeder Eintrag ist per Hash mit dem vorherigen verkettet. Wenn du die heutige Antwort speicherst und ein vergangener Monat später anders lautet, verrät es dir der Hash.

Eine Einschränkung, die wir lieber nennen als verschweigen. Ein von uns verpasster Zyklus kann noch immer als ausgeliefert verbucht werden, wenn eine von dir über die API ausgelöste Prüfung zufällig ins selbe Zeitfenster fällt; nichts in den Daten trennt die beiden Herkünfte bislang. Bestätigungs-Nachprüfungen — die, die wir von einem zweiten Standort aus fahren, um einen vermuteten Ausfall zu verifizieren — haben diesen Effekt nicht, denn sie erzeugen keinen zusätzlichen Zyklus und werden dem Zyklus zugerechnet, aus dem sie stammen. Wir kennzeichnen die Herkunft einer Prüfung künftig an der Quelle, um auch den verbleibenden Fall zu schließen.

Auf der Landingpage stand früher eine Plattform-Verfügbarkeit, die aus all dem nicht abgeleitet war. Wir haben sie entfernt. Sie kommt zurück, wenn die Messreihe lang genug ist, um für sie einzustehen — und dann ist es die gemessene.

Wir haben die Rollenbeschreibung der seven communications GmbH & Co. KG (seven.io) in unserer Subprozessoren-Liste korrigiert. Dort stand „SMS-Versand", und genannt waren nur SMS-Alarme. seven.io ist auch der Anbieter, über den unsere Sprachanruf-Alarme hinausgehen — seit es die Sprachalarmierung gibt, und der Eintrag, der im Juli LOX24 als Zweitanbieter „für SMS und Sprachanrufe" ankündigte, setzte das bereits voraus.

Das ist die Korrektur eines unvollständigen Eintrags, keine Änderung der Verarbeitung. Es kommt kein Anbieter hinzu, nichts wurde verlagert, und der Standort bleibt: seven.io ist ein deutsches Unternehmen. Was seven.io für einen Sprachanruf erhält, ist dasselbe wie bisher für eine SMS — die Rufnummer des Empfängers und den Inhalt der Benachrichtigung — und genau das steht jetzt am Eintrag.

Die vollständige Liste findest du auf der Seite Subprozessoren.

Wir haben die Zeeg GmbH (Berlin, Deutschland) aus unserer Subprozessoren-Liste entfernt. Zeeg war das Buchungswerkzeug für Demo-, Vertriebs- und Onboarding-Gespräche über unsere Website und verarbeitete dabei Name, E-Mail-Adresse und Termindetails der buchenden Person. Wir setzen den Dienst nicht mehr ein, es gehen also keine Daten mehr dorthin.

An der Plattform ändert sich nichts. Zeeg hatte nie Zugriff auf dein Konto oder auf Monitoring-Daten — der Dienst stützte ausschließlich unseren internen Geschäftsbetrieb und stand genau deshalb unter dieser Überschrift, damit der Unterschied sichtbar bleibt.

Die vollständige Liste findest du auf der Seite Subprozessoren.

Für Testkonten, in denen nie ein Zahlungsmittel hinterlegt wird, gilt ein fester Ablauf, den wir in Stufen scharf schalten: Das Monitoring pausiert 14 Tage nach der Registrierung, sieben Tage vor der Löschung geht eine Warn-E-Mail hinaus, und 30 Tage nach dem Pausieren wird das Konto samt Daten gelöscht — insgesamt 44 Tage nach der Registrierung —, sofern nicht vorher ein Zahlungsmittel hinterlegt wird. Wer eines hinterlegt, egal wann, auch mitten in der Testphase, ist von diesem Ablauf vollständig ausgenommen; einen gesonderten Widerspruch braucht es dafür nicht.

Der Datenexport bleibt über den gesamten Zeitraum erreichbar, auch nachdem das Monitoring pausiert. Es bleibt also immer Zeit, die eigenen Daten vor der Löschung zu sichern. Zahlende Konten sind davon nicht betroffen.

Jedes heute schon bestehende Konto bekommt ab jetzt volle 14 Tage, unabhängig vom ursprünglichen Registrierungsdatum — niemand wird beim Ausrollen rückwirkend deaktiviert.

Bisher ließ sich die Prüfhistorie eines einzelnen Monitors über dessen Detailseite exportieren. Ab heute exportiert ein Administrator in einem Zug alles, was die Organisation hält: Kunden, Monitore jedes Typs, Vorfälle und deren Aktualisierungen, Wartungsfenster, Benachrichtigungskanäle, Tags, Statusseiten, Reports samt Laufhistorie, Abrechnungsdaten, Teammitglieder, Metadaten der API-Token, die Konfiguration und Historie des Incident-Managements sowie die rohe Prüfhistorie hinter deinen Monitoren.

Der Export liegt im Dashboard unter Einstellungen → Datenexport und in der API (POST /api/organization/data-export). Jeder Datensatz wird doppelt geschrieben — als JSON für einen originalgetreuen Re-Import und als CSV für die Tabellenkalkulation — dazu eine manifest.json, die jeden Abschnitt mit seiner Zeilenzahl aufführt. So prüfst du die Vollständigkeit, ohne eine einzige Datei zu öffnen.

Zwei Dinge begrenzen den Inhalt, und beide stehen im Paket selbst. Zeitreihen reichen so weit zurück, wie es die in deinen Paketen enthaltene Datenaufbewahrung hergibt — ältere Zeilen werden nicht zurückgehalten, es gibt sie nicht mehr. Und Zugangsdaten verlassen die Plattform nie: Passwörter, Webhook-Secrets, Integrations-Token, API-Token-Hashes und SMTP-Passwörter werden durch eine Schwärzungsmarkierung ersetzt, während der umgebende Datensatz vollständig exportiert wird.

Wo die Datei liegt: Das ZIP wird in unseren Objektspeicher bei Hetzner in Deutschland geschrieben — derselbe Speicher, in dem bereits Report-PDFs und Branding-Assets liegen. Es kommt also kein neuer Anbieter hinzu, und deine Daten verlassen den europäischen Stack nicht. Der Download läuft über eine authentifizierte Anfrage, die einen Link mit fünf Minuten Gültigkeit ausstellt; der Bucket selbst ist nicht durchsuchbar. Sieben Tage nach der Erstellung wird die Datei automatisch gelöscht und der Eintrag als abgelaufen markiert. Der Export kostet nichts extra, und du kannst alle sechs Stunden einen anfordern.

Uptimeify prüft deine Monitore von mehreren europäischen Standorten aus und bestätigt jeden Ausfall von mehr als einem davon. Zwei dieser Standorte sind umgezogen: Die Knoten in Zürich (CH) und Prag (CZ) sind außer Dienst, an ihre Stelle treten neue Knoten in Frankfurt (DE) und Paris (FR). In Mailand und Warschau haben wir zusätzlich Kapazität aufgebaut.

Die Flotte umfasst weiterhin sieben europäische Standorte, alle innerhalb der EU: Nürnberg, Falkenstein und Frankfurt in Deutschland, dazu Paris, Warschau, Mailand und Helsinki. Geändert hat sich die Länderliste — Checks starten nicht mehr aus der Schweiz oder aus Tschechien, dafür kommt Frankreich hinzu. Am Speicherort und an der Verarbeitung deiner Daten ändert das nichts: Die Plattform bleibt in Deutschland gehostet, ein neuer Subprozessor ist nicht beteiligt.

Wenn du unsere Prüfknoten in einer Firewall freischaltest, musst du tätig werden. Die Adressen der stillgelegten Knoten sind aus uptimeify.io/ips.txt verschwunden, die neuen stehen drin. Diese Datei ist die maßgebliche Liste; wenn du eine Kopie von Hand pflegst, lies sie jetzt neu ein. Ein Blick auf Monitore, die Checks auf bestimmte Länder beschränken, lohnt sich ebenfalls — ein auf die Schweiz oder Tschechien festgelegter Monitor hat keinen Standort mehr, von dem aus er laufen könnte.

Uptimeify überwacht seine eigenen Produktionsdienste mit Uptimeify. Ein Release tauscht den Anwendungscontainer aus, was ein paar Sekunden dauert — lang genug, dass unsere eigenen Checks eine fehlgeschlagene Anfrage verzeichnen und auf der öffentlichen Statusseite einen Vorfall eröffnen. Für etwas, das von vornherein geplant war.

Ab sofort öffnet die Deployment-Pipeline für diese Monitore ein Wartungsfenster, unmittelbar bevor der Container getauscht wird, und hebt es 30 Sekunden nach dem Release wieder auf. Während eines Releases zeigt unsere Statusseite deshalb geplante Wartung statt eines Vorfalls, und die Verfügbarkeitswerte unserer Produktionsdienste rechnen unsere eigenen Deployments nicht mehr als Ausfall.

Das Fenster ist bewusst kurzlebig und läuft von selbst ab: Scheitert ein Release oder wird es abgebrochen, hebt die Pipeline das Fenster sofort auf, damit echte Alarme wieder greifen — und selbst eine Pipeline, die mitten im Lauf stirbt, hinterlässt ein Fenster, das von allein verfällt. Für deine eigenen Monitore, deine Alarmierung und die Verarbeitung deiner Daten ändert sich nichts.

Bisher wurde jedes Release der Uptimeify-Web-Anwendung auf dem Anwendungsserver selbst kompiliert. Ab heute entsteht das Image zuerst in unseren CI-Runnern und wird dort geprüft; der Server holt sich nur noch das fertige, versionsfixierte Image und ersetzt den laufenden Container. Deployments dauern kürzer, das Wartungsfenster während eines Releases ist kleiner, und dasselbe geprüfte Artefakt lässt sich auf mehr als einen Anwendungsserver ausrollen — die Grundlage dafür, die App künftig redundant über mehrere Hosts zu betreiben.

Im selben Zug haben wir die letzten Reste des alten Einzelserver-Aufbaus entfernt. Die Anwendungsdatenbank ist im Juli auf ein hochverfügbares Patroni-PostgreSQL-Cluster umgezogen, die Queue- und Cache-Schicht kurz darauf auf ein Redis-Sentinel-Cluster. Beide Cluster laufen auf eigenen Hosts unserer EU-Infrastruktur und sind nur über unser privates Netz erreichbar. Die ungenutzten lokalen PostgreSQL- und Redis-Container auf dem Anwendungsserver sind jetzt abgeschaltet — der Anwendungs-Host speichert damit überhaupt keine Kundendaten mehr.

Alles bleibt auf unserer bestehenden europäischen Infrastruktur. Kein neuer Subprozessor, keine Änderung daran, wie deine Daten verarbeitet werden, und nichts, was du tun müsstest.

KI-Agenten, die sich am Autorisierungsserver für agentische Registrierung (https://uptimeify.io) registrieren, lassen sich jetzt beanspruchen: Du autorisierst im angemeldeten Zustand einen bestimmten Agenten, indem du auf der Seite /claim einen kurzen Code bestätigst — entweder einen Agenten, der die Zeremonie direkt gestartet hat (service_auth), oder eine bestehende anonyme Registrierung, die über POST /agent/identity/claim hochgestuft wurde. Nach der Bestätigung erhält der Agent ein ausschließlich lesendes Zugriffstoken, begrenzt auf deine Organisation — oder auf einen einzelnen Kunden, wenn deine Rolle darauf beschränkt ist.

Ein beanspruchter Agent kann Websites, Vorfälle und Health-Status lesen. Anlegen, ändern oder löschen kann er nichts. Den Zugriff nimmst du jederzeit über den bestehenden Endpunkt zum Widerruf von Token zurück. Die vollständige Zeremonie steht in der API-Dokumentation unter „Agentic registration → Claim flow". Neue Drittanbieter oder Subprozessoren sind daran nicht beteiligt.

Uptimeify zeigt dir jetzt unter Einstellungen → Verbundene Anwendungen jede Anwendung, die du per OAuth verbunden hast, zum Beispiel Claude an /mcp. Dort entziehst du den Zugriff jederzeit. Der Widerruf trennt die Anwendung sofort — sie kann deine Daten nicht mehr lesen — und eine erneute Verbindung verlangt eine neue Freigabe. Jede Verbindung ist ausschließlich lesend und auf dein eigenes Konto begrenzt. Ein neuer Drittanbieter ist daran nicht beteiligt.

Der Model-Context-Protocol-Server unter https://uptimeify.io/mcp bietet jetzt authentifizierte, ausschließlich lesende Werkzeuge. Schickt ein KI-Agent ein Uptimeify-API-Token als Authorization: Bearer-Header, kann er deine Website-Monitore auflisten, den aktuellen Status eines Monitors lesen, jüngste Vorfälle auflisten, die Prüfhistorie abrufen und eine Verfügbarkeitsübersicht holen. Der Zugriff ist exakt so begrenzt wie in der REST-API: Ein kundengebundenes Token sieht nur die Daten dieses Kunden, ein Organisations-Token die ganze Organisation — und alle Werkzeuge lesen ausschließlich. Weder die Datenverarbeitung noch Drittanbieter ändern sich dadurch.

Der Endpunkt /mcp von Uptimeify — genutzt von Claude und anderen MCP-fähigen Clients — unterstützt jetzt neben statischen API-Token auch das Standard-OAuth-Verfahren für MCP (OAuth 2.1, PKCE und Dynamic Client Registration). Eine Verbindung über OAuth gewährt ausschließlich lesenden Zugriff auf deine eigenen Monitore, Vorfälle und Statusseiten, exakt im Rahmen der Sichtbarkeit, die dein Konto ohnehin hat. Anlegen, ändern oder löschen kann sie nichts. Ein neuer Drittanbieter ist daran nicht beteiligt; das läuft auf unserer bestehenden Anwendungs- und Datenbank-Infrastruktur.

Uptimeify betreibt jetzt einen Autorisierungsserver für agentische Registrierung im WorkOS-Stil, auf derselben Origin unter https://uptimeify.io. KI-Agenten finden ihn über /.well-known/oauth-authorization-server und /.well-known/oauth-protected-resource, registrieren sich anonym unter /agent/identity, tauschen unter /oauth2/token eine signierte Identitätsbehauptung gegen ein kurzlebiges, opakes Zugriffstoken und ziehen es unter /oauth2/revoke wieder zurück. Agenten-Token sind hart auf lesende GET- und HEAD-Anfragen einer ausdrücklichen Allowlist begrenzt und können keinerlei Schreibvorgang auslösen. Der Signaturschlüssel ist ein Ed25519-Schlüssel aus der Umgebung; fehlt er, bleibt die Funktion vollständig aus. Neue Drittanbieter oder Subprozessoren sind daran nicht beteiligt.

Wir haben zwei Subprozessoren aufgenommen, die unseren internen Geschäftsbetrieb stützen. Die easybell GmbH (Berlin, Deutschland) stellt unsere Unternehmenstelefonie bereit: den SIP-Trunk und die Cloud-Telefonanlage hinter unserer Firmennummer. Die Zeeg GmbH (Berlin, Deutschland) ist das Buchungswerkzeug für Demo-, Vertriebs- und Onboarding-Gespräche über unsere Website; verarbeitet werden Name, E-Mail-Adresse und Termindetails der buchenden Person. Beide Anbieter sitzen in der EU (Deutschland) und sind über einen Auftragsverarbeitungsvertrag gebunden. Keiner von beiden hat Zugriff auf dein Konto oder auf Monitoring-Daten. Beide stehen auf unserer Subprozessoren-Seite.

KI-Agenten können die kostenlosen Prüfwerkzeuge von Uptimeify jetzt direkt über das Model Context Protocol (MCP) nutzen. Ein zustandsloser MCP-Endpunkt unter https://uptimeify.io/mcp stellt rund zwanzig anonyme, ausschließlich lesende Werkzeuge bereit: SSL/TLS-Prüfung, DNS- und Mail-Zustellbarkeitsprüfungen (SPF, DKIM, DMARC, MX), Analyse von HTTP-Headern und Weiterleitungen, WHOIS, Blacklist- und Erreichbarkeitsprüfungen. Agenten finden den Server über die MCP Server Card unter /.well-known/mcp/server-card.json. Für diese Werkzeuge braucht es weder Konto noch Anmeldung.

Damit unsere Checks aus einer breiteren Infrastruktur heraus laufen, haben wir zwei EU-Cloud-Anbieter aufgenommen, die zusätzliche Monitoring-Check-Knoten hosten: die netcup GmbH (Deutschland) und die UpCloud Ltd (Finnland). Weil Check-Knoten die Hostnamen überwachter Ziele und deren Ergebnisse sehen, stehen beide jetzt auf unserer Subprozessoren-Seite. Beide arbeiten innerhalb der EU; an deinen Monitoren, deinen Daten und deiner Alarmierung ändert sich nichts.

Die interne Queue- und Cache-Schicht, die Check-Planung, Alarm- und Benachrichtigungszustellung, Reports und kurzlebiges Caching antreibt, hing bisher an einer einzelnen Redis-Instanz — ein einzelner Ausfallpunkt für diesen Teil der Pipeline. Wir haben sie hinter ein Redis-Sentinel-Cluster über drei Knoten auf unserer eigenen EU-Infrastruktur gelegt: Sentinel beobachtet den Primärknoten laufend und befördert, sobald er nicht mehr erreichbar ist, eine Replik zum Primär und verbindet die Worker automatisch neu. Monitoring und Alarmierung laufen weiter, ohne dass jemand eingreifen muss.

Das ist eine interne Zuverlässigkeitsänderung: vollständig selbst gehostet auf unserer bestehenden Hetzner-Infrastruktur, ohne neuen Drittanbieter, ohne etwas, das du tun müsstest. Deine Monitore, deine Alarmkanäle und deine Daten bleiben unberührt.

Unsere Monitoring-Knoten lösen die Hostnamen, die sie prüfen, über lokale cachende DNS-Resolver auf unserer eigenen Hetzner-Infrastruktur auf. An ungefilterte Public Resolver leiten sie nur im Fallback weiter — dann, wenn unsere eigenen primären Resolver kurzzeitig ausgelastet sind.

Wir haben Quad9, eine Non-Profit-Stiftung mit Sitz in Zürich, Schweiz, durch DNS.SB ersetzt, betrieben von der xTom GmbH in Deutschland. Dieser zweite Fallback sitzt damit vollständig in der EU. DNS.SB ist ein ungefilterter Resolver, der keine Anfrage-Protokolle führt: Keine rechtmäßig überwachte Domain wird blockiert, keine Auflösungsdaten werden aufbewahrt. DNS4EU bleibt als unser anderer EU-Fallback bestehen.

Weil ein Fallback-Resolver die Hostnamen überwachter Ziele zu sehen bekommen kann, steht DNS.SB jetzt anstelle von Quad9 auf unserer Subprozessoren-Seite. Im Übrigen bleibt die Auflösung auf unserer eigenen Infrastruktur, und DNS-Blocklisten-Prüfungen (DNSBL) lösen weiterhin ohne jeden Drittanbieter-Forwarder auf.

Wir haben eine E-Mail-basierte Alarmquelle ergänzt: Du kannst eine Alarm-Mail aus jedem Werkzeug, das Alarme per E-Mail verschickt — ein altes Bereitschaftssystem, ein Anbieter ohne Webhook, ein internes Skript — an eine eigene Adresse unter @ingest.uptimeify.io weiterleiten, und daraus wird ein Vorfall, genau wie aus einem Webhook-Alarm.

Lettermint (Lettermint B.V., Niederlande, EU) — schon bisher unser Anbieter für ausgehende Transaktions-E-Mails wie Alarmbenachrichtigungen, Reports und Konto-Mails — verarbeitet jetzt auch diesen EINGEHENDEN Verkehr. Trifft eine Mail an einer Eingangsadresse ein, nimmt Lettermint sie entgegen und reicht ihren Inhalt (Absender, Betreff und Text) über einen authentifizierten Webhook an unsere Plattform weiter. Es kam kein neuer Anbieter hinzu; ein bestehender hat eine erweiterte Rolle bekommen, und Lettermint bleibt in beide Richtungen in der EU (Niederlande) ansässig.

Der Eintrag zu Lettermint in unserer Subprozessoren-Übersicht ist um diese erweiterte Rolle ergänzt.

SMS und Sprachanruf sind die letzte Linie der Alarmierung — sie erreichen einen Menschen, wenn E-Mail und Chat es nicht tun. Bisher liefen beide über einen einzigen Anbieter, seven.io. Damit hing der lauteste Teil unserer Alarmierung daran, dass ein einzelner Dienstleister genau in dem Moment verfügbar ist, in dem es am meisten zählt.

Wir haben LOX24 (LOX24 GmbH, Deutschland) als zweiten Anbieter für SMS- und Sprachbenachrichtigungen aufgenommen. Er steht auf Cold Standby: Jede Nachricht geht zuerst über seven.io hinaus, LOX24 kommt nur zum Einsatz, wenn seven.io nicht zustellen kann. Zwei unabhängige Carrier, zwei unabhängige Fehlerbilder — genau darum geht es.

Um eine SMS zu senden oder einen Alarmanruf aufzubauen, erhält LOX24 die Rufnummer des Empfängers und den Text der Benachrichtigung. Mehr wird nicht übergeben, und an keinem anderen Teil der Plattform ist der Dienst beteiligt. Die LOX24 GmbH ist ein deutsches Unternehmen, ein Auftragsverarbeitungsvertrag nach Art. 28 DSGVO liegt vor. Der Anbieter steht jetzt in unserer Subprozessoren-Übersicht.

Jeder Monitoring-Knoten löst die Hostnamen, die er prüft, über lokale cachende DNS-Resolver auf, die neben den Workern auf unserer eigenen Hetzner-Infrastruktur laufen. Kein Drittanbieter-Resolver sieht, welche Domains wir überwachen. Bei einem Schwall gleichzeitiger Checks konnten diese Resolver kurz an ihre Kapazitätsgrenze stoßen und ein vorübergehendes „temporary failure in name resolution" (EAI_AGAIN) zurückgeben — was einzelne Checks als „Ziel nicht erreichbar" lasen, obwohl die Seite lief und Sekunden später sauber auflöste.

Wir haben den Resolvern mehr Nebenläufigkeits-Reserve gegeben, sodass Lastspitzen aus dem lokalen Cache bedient werden statt zu scheitern, und das DNS-Retry-Fenster der Worker verbreitert, sodass ein Aussetzer im Sekundenbruchteil abgefangen wird, bevor ein Check überhaupt als fehlgeschlagen aufgezeichnet ist. Eine wirklich nicht auflösbare Domain scheitert weiterhin sofort und alarmiert wie zuvor. Es kam kein Anbieter hinzu und keiner wurde gewechselt: Die Auflösung bleibt vollständig bei uns.

Unsere Monitoring-Knoten lösen die Hostnamen, die sie prüfen, über lokale cachende DNS-Resolver auf unserer eigenen Hetzner-Infrastruktur auf; diese leiten an vorgelagerte rekursive Resolver weiter. Bisher hing diese Weiterleitung an einem einzigen vorgelagerten Anbieter — eine kurze Sättigung dort konnte als vorübergehender Auflösungsfehler durchschlagen und in seltenen Fällen einen falschen Ausfall-Alarm erzeugen, obwohl die Seite lief.

Wir haben zwei unabhängige, datenschutzorientierte und ungefilterte Public Resolver als Fallback aufgenommen: DNS4EU, die europäische Public-Resolver-Initiative mit Betrieb innerhalb der EU, und Quad9, eine Non-Profit-Stiftung mit Sitz in Zürich, Schweiz. Wir nutzen bewusst deren ungefilterte Varianten, damit keine rechtmäßig überwachte Domain je blockiert wird. Weil diese Resolver die Hostnamen überwachter Ziele zu sehen bekommen können, stehen beide jetzt auf unserer Subprozessoren-Seite. Im Übrigen bleibt die Auflösung auf unserer eigenen Infrastruktur, und DNS-Blocklisten-Prüfungen (DNSBL) lösen weiterhin ohne jeden Drittanbieter-Forwarder auf.

Es gibt einen eigenen Monitor-Typ TCP-Port. Richte ihn auf einen beliebigen Host und Port, und wir prüfen aus unserer europäischen Monitoring-Flotte, ob der Port innerhalb deines Timeouts eine TCP-Verbindung annimmt — auf Wunsch zusätzlich, ob die erste Antwort des Dienstes (sein Banner) einen erwarteten Textabschnitt enthält. Zugangsdaten braucht es dafür nicht.

Dazu kommt ein Prüfmodus „nur Port" für die bestehenden SSH-, SMTP-, FTP- und IMAP/POP-Monitore. In diesem Modus führt der Monitor dieselbe reine TCP-Erreichbarkeitsprüfung durch statt eines vollständigen Protokoll-Handshakes samt Anmeldung — du kannst den Port eines Dienstes also beobachten, ohne irgendwelche Zugangsdaten zu hinterlegen. Der Standardmodus „Protokoll" mit vollem Handshake und Authentifizierung bleibt für jeden bestehenden Monitor unverändert.

Die Checks laufen über dieselben Monitoring-Knoten und dieselbe Alarm-Pipeline wie unsere übrigen Service-Monitore: keine neuen Subprozessoren, keine Änderung an der Datenverarbeitung.

Unsere CI/CD-Pipelines laufen jetzt auf verwalteten GitHub-Actions-Runnern von Ubicloud. Ubicloud verarbeitet dabei unseren Quellcode und unsere Build-Secrets — keine Monitoring-Daten von Kunden.

Vertragspartner ist die niederländische Ubicloud B.V., die Muttergesellschaft Ubicloud, Inc. sitzt allerdings in den USA (San Francisco). Ein US-Zugriffspfad lässt sich damit nicht vollständig ausschließen; er ist über Standardvertragsklauseln abgedeckt. Der Dienst steht jetzt in unserer Subprozessoren-Übersicht.

Wir haben eine Zuständigkeitsklasse pro Monitor eingeführt, über alle Monitor-Typen hinweg: Website, DNS, ICMP, SMTP, SSH, FTP, IMAP/POP, Domain-Ablauf und DNSBL. Managed verhält sich exakt wie bisher — die Organisation betreibt den Monitor, die vollständige Eskalation greift. Self-Service liegt beim Endkunden: Nutzer im Kundenportal legen solche Monitore innerhalb ihres Paket-Kontingents selbst an, bearbeiten und löschen sie, und die Alarme gehen ausschließlich an die Empfänger dieses Kunden. Organisationsweite Integrationskanäle — Webhooks, OpsGenie, Org-SMTP — bleiben dabei außen vor.

Alle bestehenden Monitore wurden als managed eingestuft. Für keinen laufenden Monitor hat sich damit etwas geändert, solange eine Organisation Self-Service nicht ausdrücklich aktiviert. Die API hat die passenden Felder und einen Änderungsantrags-Ablauf bekommen; Details stehen in der Dokumentation.

Die primäre Datenbank hinter Uptimeify ist von einem Einzelknoten-Container auf ein von Patroni verwaltetes, hochverfügbares PostgreSQL/TimescaleDB-Cluster mit automatischem Leader-Failover umgezogen. Bereitstellung und Backups laufen jetzt über einen eigenen Infrastructure-as-Code-Stack (Ansible) statt über die Anwendungs-Deployment-Pipeline — datenkritische Vorgänge sind damit von gewöhnlichen Releases getrennt. Alle Daten bleiben auf unserer eigenen Infrastruktur in Deutschland; weder Anbieter noch Speicherort ändern sich.

Wir haben die protokollspezifischen Check-Worker auf einer einzigen gehärteten Check-Engine zusammengeführt und sie an alle Monitoring-Standorte ausgerollt. Was das für deine Monitore bedeutet: identische Sicherheits- und Zuverlässigkeitsvorkehrungen über jedes Protokoll hinweg, inklusive SSRF-Schutz und einheitlichem Verbindungs-Retry. Antwortzeiten für SMTP-, SSH-, FTP- und IMAP/POP-Checks messen jetzt die Protokollverbindung selbst — die DNS-Auflösung zählt nicht mehr mit, die Werte können also etwas niedriger und gleichmäßiger ausfallen. Und DNS-Monitore, die lange TXT-Records vergleichen (etwa DKIM-Schlüssel über 255 Zeichen), treffen jetzt korrekt zu, statt eine Abweichung zu melden, die keine war.

Wir haben eine aktualisierte Monitoring-Worker-Version an alle Check-Standorte ausgerollt. Das Wichtigste: Wartungsfenster unterdrücken DNSBL-Benachrichtigungen (Blocklisten) jetzt zuverlässig. DNSBL- und Domain-Ablauf-Alarme gehen an alle Integrationskanal-Typen, etwa Telegram, Opsgenie und PagerDuty. Redirect-Loops werden vor dem Alarm mit einem echten Browser verifiziert und bringen einen Screenshot als Beleg mit. Dazu kommt eine breite Reihe interner Härtungen für Zuverlässigkeit und Sicherheit entlang der gesamten Check-Pipeline.

Wir setzen jetzt fastmon (fastmon labs UG (haftungsbeschränkt), Deutschland) für Real User Monitoring (RUM) ein. Erfasst werden Performance- und Ladezeit-Telemetrie von Besuchern der Uptimeify-Web-Anwendung, damit wir die Frontend-Performance messen und verbessern können. fastmon verarbeitet keine Monitoring-Daten — keine überwachten URLs, keine Prüfergebnisse, keine Alarm-Inhalte — und wird in Deutschland gehostet. Der Dienst steht jetzt in unserer Subprozessoren-Übersicht.

Wir setzen jetzt Leadfeeder (Dealfront Group GmbH, Deutschland) für B2B-Besucheranalyse auf unserer öffentlichen Website ein. Der Dienst zeigt uns, welche Unternehmen die Seite besuchen, damit wir Vertrieb und Marketing darauf ausrichten können. Er läuft ausschließlich nach ausdrücklicher Cookie-Einwilligung und niemals innerhalb der Monitoring-Anwendung. Monitoring-Daten verarbeitet er nicht: keine überwachten URLs, keine Prüfergebnisse, keine Alarm-Inhalte. Der Dienst steht jetzt in unserer Subprozessoren-Übersicht.

Die Produktdokumentation ist auf eine eigene Subdomain umgezogen: docs.uptimeify.io, gehostet auf unserem bestehenden EU-Anwendungsserver (Hetzner). Alle bisherigen Links unter uptimeify.io/docs/… funktionieren weiter, per dauerhafter Weiterleitung (301). Keine Änderung an der Datenverarbeitung, keine neuen Subprozessoren: Das ist eine Umsortierung der Auslieferung, keine Verlagerung deiner Daten.

Unsere Monitoring-Worker-Knoten haben Website- und Service-Checks bisher ausschließlich über IPv4 ausgeführt. Wir haben IPv6-Egress an allen Monitoring-Standorten aktiviert: Ein Check nutzt jetzt die Adressfamilie, die eine Seite tatsächlich veröffentlicht (Dual-Stack) — so, wie echte Besucher sie erreichen.

Für Seiten mit einer IPv6-Adresse (AAAA-Record) werden die Erreichbarkeitsergebnisse dadurch genauer. Fehlalarme vom Typ „Verbindung fehlgeschlagen" fallen weg, die entstehen konnten, wenn ein Check von einem Standort aus IPv6 versuchte, dessen Container-Networking nur IPv4 sprach. Du musst nichts tun. An der Datenverarbeitung und an unseren Drittanbietern ändert sich nichts: Das ist eine interne Netzwerkfähigkeit unserer eigenen Monitoring-Infrastruktur.

In unserer Datenschutzerklärung stand Cloudflare bislang als CDN/DNS-Anbieter. Cloudflare ist nicht Teil unserer Infrastruktur, deshalb ist der Abschnitt aus der deutschen wie der englischen Fassung verschwunden. Bei derselben Durchsicht haben wir klargestellt: Unser Error-Tracking läuft selbst gehostet (Bugsink) auf Hetzner-Servern in Deutschland. Keine Fehlerdaten verlassen unsere eigene Infrastruktur.

Wir haben eine öffentliche Subprozessoren-Übersicht veröffentlicht: /de/subprozessoren (englisch: /subprocessors). Sie führt jeden Drittanbieter auf, der am Betrieb von Uptimeify beteiligt ist — ob er Monitoring-Daten verarbeitet und wo er sitzt — dazu die optionalen, von dir selbst eingerichteten Benachrichtigungs-Integrationen. Künftige Änderungen an unserer Infrastruktur oder an unseren Subprozessoren kündigen wir über dieses Changelog und seinen RSS-Feed an.