Plattform-Update Juli 2026: 27 Änderungen, zwei davon mit Aufwand für dich

Hinweis, August 2026: Dieser Beitrag beschreibt den Stand von Juli 2026. Seit August 2026 läuft die Flotte über neun europäische Standorte in Deutschland, Spanien, Frankreich, Italien, Polen und Finnland. Die aktuelle Liste steht unter Plattform und Support.

Im Juli sind 27 Änderungen an der Plattform live gegangen. Eine davon verlangt etwas von dir: Zwei unserer Prüfstandorte sind umgezogen, und wenn du unsere IP-Adressen in einer Firewall führst, musst du die Liste neu einlesen. Der Rest ist zum Mitnehmen: ein vollständiger Datenexport für deine ganze Organisation, ein eigener Monitor-Typ für TCP-Ports, ein zweiter Anbieter für SMS- und Sprachalarme und ein Maschinenraum, der jetzt ohne einzelne Ausfallpunkte auskommt.

Was du tun musst: neue Prüfstandorte, neue IP-Liste

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 seit dem 28. Juli umgezogen: Die Knoten in Zürich und Prag sind außer Dienst, an ihre Stelle treten Frankfurt und Paris. In Mailand und Warschau haben wir zusätzlich Kapazität aufgebaut.

Die Flotte umfasst weiterhin sieben 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.

Zwei Dinge lohnen einen Blick, wenn du Kundeninfrastruktur betreust:

Deine Daten gehören dir: Export für die ganze Organisation

Bisher ließ sich die Prüfhistorie eines einzelnen Monitors über dessen Detailseite exportieren. Seit dem 30. Juli 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.

Du findest den Export im Dashboard unter Einstellungen, Datenexport, und in der API unter 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 schlicht 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.

Das ZIP wird in unseren Objektspeicher bei Hetzner in Deutschland geschrieben, denselben Speicher, in dem bereits Report-PDFs und Branding-Assets liegen. 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. Der Export kostet nichts extra, und du kannst alle sechs Stunden einen anfordern.

Im selben Zug haben wir den Ablauf für unbezahlte Testkonten festgeschrieben: Monitoring pausiert 14 Tage nach der Registrierung, sieben Tage vor der Löschung geht eine Warn-E-Mail raus, 30 Tage nach dem Pausieren wird das Konto samt Daten gelöscht. Wer ein Zahlungsmittel hinterlegt, egal wann, ist davon vollständig ausgenommen. Der Datenexport bleibt über den gesamten Zeitraum erreichbar, auch nachdem das Monitoring pausiert.

Neu überwachbar: TCP-Ports, mit und ohne Zugangsdaten

Seit dem 12. Juli gibt es einen eigenen Monitor-Typ TCP-Port. Richte ihn auf einen beliebigen Host und Port, und wir prüfen aus unserer europäischen 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-Monitore. In diesem Modus führt der Monitor dieselbe reine TCP-Erreichbarkeitsprüfung durch statt eines vollständigen Protokoll-Handshakes samt Anmeldung. Für Agenturen ist das der praktische Teil: Du kannst den Mailserver eines Kunden beobachten, ohne dass jemand dir ein Passwort in ein Ticket schreibt. Der Standardmodus mit vollem Handshake bleibt für jeden bestehenden Monitor unverändert.

Ebenfalls neu ist eine Zuständigkeitsklasse pro Monitor, über alle Typen hinweg. 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 Kontingents selbst an, bearbeiten und löschen sie, und die Alarme gehen ausschließlich an die Empfänger dieses Kunden. Organisationsweite Integrationskanäle wie Webhooks, OpsGenie oder ein eigener SMTP-Kanal bleiben dabei außen vor. Alle bestehenden Monitore wurden als managed eingestuft, für keinen laufenden Monitor hat sich damit etwas geändert.

Alarmierung: zwei Carrier statt einem, und eine Adresse für alles Alte

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. Damit hing der lauteste Teil der Alarmierung daran, dass ein einzelner Dienstleister genau in dem Moment verfügbar ist, in dem es am meisten zählt.

Seit dem 17. Juli steht LOX24 als zweiter Anbieter im 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. Übergeben werden dabei ausschließlich die Rufnummer des Empfängers und der Text der Benachrichtigung.

Dazu kommt eine E-Mail-basierte Alarmquelle. Du kannst eine Alarm-Mail aus jedem Werkzeug, das Alarme per E-Mail verschickt, an eine eigene Adresse unter @ingest.uptimeify.io weiterleiten, und daraus wird ein Vorfall, genau wie aus einem Webhook-Alarm. Ein altes Bereitschaftssystem, ein Anbieter ohne Webhook, ein internes Skript: Alles, was eine Mail senden kann, landet damit in derselben Eskalation wie der Rest.

Und weil wir unsere eigene Produktion mit Uptimeify überwachen, öffnet die Deployment-Pipeline seit dem 27. Juli für die betroffenen Monitore ein Wartungsfenster, unmittelbar bevor der Anwendungscontainer getauscht wird, und hebt es 30 Sekunden nach dem Release wieder auf. Unsere Statusseite zeigt während eines Releases geplante Wartung statt eines Vorfalls. Scheitert ein Release, hebt die Pipeline das Fenster sofort auf, damit echte Alarme wieder greifen.

Für KI-Agenten: lesender Zugriff, sauber begrenzt

Der MCP-Server unter https://uptimeify.io/mcp hat im Juli drei Ausbaustufen bekommen. Anonym stellt er rund zwanzig kostenlose Prüfwerkzeuge bereit: SSL- und TLS-Prüfung, DNS- und Mail-Zustellbarkeitsprüfungen für SPF, DKIM, DMARC und MX, Analyse von HTTP-Headern und Weiterleitungen, WHOIS sowie Blacklist- und Erreichbarkeitsprüfungen. Dafür braucht es weder Konto noch Anmeldung.

Mit einem API-Token oder über eine OAuth-Verbindung liest ein Agent zusätzlich deine eigenen Daten: Website-Monitore auflisten, aktuellen Status abrufen, jüngste Vorfälle einsehen, Prüfhistorie und 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. Alle Werkzeuge lesen ausschließlich, keines schreibt.

Verbundene Anwendungen siehst du jetzt unter Einstellungen, Verbundene Anwendungen, und entziehst ihnen dort jederzeit den Zugriff. Der Widerruf trennt die Anwendung sofort, eine erneute Verbindung verlangt eine neue Freigabe. Wer Agenten ohne eigenes Konto arbeiten lassen will, findet unter derselben Origin einen Autorisierungsserver für agentische Registrierung samt Bestätigungs-Zeremonie über die Seite /claim. Auch dieser Weg endet bei einem Token, das nur lesen darf.

Was im Maschinenraum passiert ist

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

• Datenbank auf Cluster. Die primäre Datenbank ist von einem Einzelknoten-Container auf ein von Patroni verwaltetes, hochverfügbares PostgreSQL- und TimescaleDB-Cluster mit automatischem Leader-Failover umgezogen. Bereitstellung und Backups laufen über einen eigenen Infrastructure-as-Code-Stack, getrennt von gewöhnlichen Releases.
• Queue und Cache auf Cluster. Check-Planung, Alarmzustellung, Reports und Caching hingen an einer einzelnen Redis-Instanz. Jetzt liegen sie hinter einem Redis-Sentinel-Cluster über drei Knoten: Fällt der Primärknoten aus, wird eine Replik befördert und die Worker verbinden sich automatisch neu.
• Deployments mit vorgebautem Image. Releases werden nicht mehr auf dem Anwendungsserver kompiliert, sondern in CI gebaut und geprüft. Der Server holt nur noch das fertige, versionsfixierte Image. Kürzere Deployments, kleineres Wartungsfenster, und dasselbe Artefakt lässt sich auf mehrere Anwendungsserver ausrollen.
• Anwendungsserver ohne Kundendaten. Die ungenutzten lokalen Datenbank- und Cache-Container auf dem Anwendungsserver sind abgeschaltet. Der Host speichert damit überhaupt keine Kundendaten mehr.
• Robustere DNS-Auflösung. Bei Lastspitzen konnten unsere lokalen Resolver kurz an die Kapazitätsgrenze stoßen und einen vorübergehenden Auflösungsfehler zurückgeben, den einzelne Checks als "Ziel nicht erreichbar" lasen. Wir haben die Nebenläufigkeits-Reserve erhöht und das Retry-Fenster verbreitert. Eine wirklich nicht auflösbare Domain scheitert weiterhin sofort und alarmiert wie zuvor.
• Einheitliche Check-Engine. Die protokollspezifischen Worker laufen auf einer gemeinsamen, gehärteten Engine, inklusive SSRF-Schutz und einheitlichem Verbindungs-Retry. Antwortzeiten für SMTP-, SSH-, FTP- und IMAP-Checks messen jetzt die Protokollverbindung selbst, ohne DNS-Auflösung. Die Werte können dadurch etwas niedriger und gleichmäßiger ausfallen. DNS-Monitore, die lange TXT-Records vergleichen, etwa DKIM-Schlüssel über 255 Zeichen, treffen jetzt korrekt zu.
• Alarm-Details. Wartungsfenster unterdrücken DNSBL-Benachrichtigungen zuverlässig, DNSBL- und Domain-Ablauf-Alarme gehen an alle Integrationskanäle, und Redirect-Loops werden vor dem Alarm mit einem echten Browser verifiziert und bringen einen Screenshot als Beleg mit.

Neue und gewechselte Subprozessoren

Neun Einträge haben sich im Juli bewegt. Sitz und Rolle jeweils in Kurzform, die vollständige Liste steht auf der Subprozessoren-Seite.

Drei Anmerkungen, die in eine Tabelle nicht passen. Erstens: Der Wechsel von Quad9 zu DNS.SB verlegt unseren zweiten Fallback-Resolver vollständig in die EU. DNS.SB ist ein ungefilterter Resolver ohne Anfrage-Protokolle, keine rechtmäßig überwachte Domain wird blockiert. Zweitens: Bei Ubicloud ist Vertragspartner die niederländische Gesellschaft, die Muttergesellschaft sitzt allerdings in den USA. Ein US-Zugriffspfad lässt sich damit nicht vollständig ausschließen, er ist über Standardvertragsklauseln abgedeckt. Ubicloud verarbeitet unseren Quellcode und unsere Build-Secrets, keine Monitoring-Daten von Kunden. Drittens: fastmon und Leadfeeder berühren ausschließlich unsere öffentliche Website und die Web-Anwendung, keine überwachten URLs, keine Prüfergebnisse, keine Alarm-Inhalte.

Was als Nächstes ansteht

Die Arbeit an redundanten Anwendungsservern läuft weiter. Mit dem vorgebauten Image und den beiden Clustern liegt die Grundlage dafür, die App über mehr als einen Host zu betreiben. Was konkret 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.