Uptimeify-Bots: Was sie abrufen und wie du sie blockierst

Die automatisierten Clients, die Uptimeify betreibt: was jeder abruft, wie oft, von welchen Adressen, und wie du ihn stoppst, ohne uns vorher zu schreiben.

Du bist vermutlich hier, weil in deinen Logs einer unserer Namen auftaucht und du zwei Antworten brauchst: Was ist das, und wie stelle ich es ab. Beides steht auf dieser Seite, und für beides musst du uns nicht erst schreiben.

Wir betreiben drei automatisierte Clients gegen das öffentliche Internet. Jeder weist sich aus, jeder kommt aus einem veröffentlichten Adressbereich, jeder lässt sich an deiner Edge blockieren. Einer davon läuft in einem Prüfintervall, das jemand auf deiner Seite selbst gewählt hat. Den zu blockieren hat eine Folge, die du vorher kennen solltest.

SiteMonitorBot

Bestellt von dem, der die Seite betreibt. Kommt in festem Takt, aus veröffentlichten Adressen.

UptimeifyStatusBot

Liest eine öffentliche Statuszusammenfassung pro Minute. Sonst wird nichts auf dem Host angefasst.

UptimeifyToolsBot

Eine Anfrage, weil ein Mensch oder ein KI-Agent danach gefragt hat. Kein Zeitplan dahinter.

Unsere Bots

SiteMonitorBot

Vom Betreiber bestellt
User-Agent
SiteMonitorBot/1.0 (+https://uptimeify.io)

Geht beim primären Check jedes Monitors raus. Prüfe auf die Teilzeichenkette SiteMonitorBot, nie auf den ganzen String.

Was er tut
Prüft eine Website, einen Endpoint oder einen Dienst, weil der Betreiber uns darum gebeten hat. Wenn er in deinen Logs steht, hat jemand mit Zugriff auf deine Infrastruktur dafür einen Monitor eingerichtet.
Zusätzlicher Header
X-Uptimeify-Monitor: 1
Häufigkeit
Das Prüfintervall, das der Betreiber des Monitors eingestellt hat, aus jedem von ihm aktivierten Standort.
Befolgt robots.txt
Nein. Ein Monitor wird bestellt, nicht entdeckt, und ein Disallow von dritter Seite würde einen Check abschalten, auf den sich jemand in deinem eigenen Team verlässt.
Quelladressen
Veröffentlicht und maschinenlesbar, aktualisiert, sobald sich die Flotte ändert.
uptimeify.io/ips.txt

Zwei Ausnahmen solltest du kennen, bevor du eine Regel schreibst.

Browserbasierte Checks (Screenshots und Playwright-Monitore) senden einen echten Chrome-User-Agent, an den unser Token angehängt ist, nicht ersetzt:

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/149.0.0.0 Safari/537.36 SiteMonitorBot/1.0 (+https://uptimeify.io)

Ein Playwright-Monitor läuft eine echte Nutzerreise ab, etwa einen Login oder einen Checkout, und viele WAFs blocken einen nackten, unbekannten User-Agent sofort. Das würde einen Ausfall melden, den niemand erlebt. Deshalb bleibt die Browser-Form erhalten und unser Name kommt dazu, statt sie zu ersetzen. Ein Substring-Match fängt das weiterhin; ein Match auf den ganzen String nicht, weil sich der Chrome-Teil mit jedem Browser-Update ändert.

Keyword- und Expected-Response-Checks laufen als eigene Anfragen zusätzlich zum primären Check und tragen derzeit weder das Token noch den Header, stattdessen geht ein gewöhnlicher Desktop-Chrome-User-Agent raus. Ein Match auf unseren Namen stoppt sie nicht. Ein Match auf die Adressen schon.

UptimeifyStatusBot

Liest öffentliche Statusseiten
User-Agent
UptimeifyStatusBot/1.0 (+https://uptimeify.io/robot)

Geht bei jeder Anfrage raus, ausnahmslos.

Was er tut
Liest die öffentlichen Statusseiten, die andere Unternehmen über sich selbst veröffentlichen, damit wir unseren Kunden sagen können, wenn ein Dienst, von dem sie abhängen, gerade Probleme meldet.
Was er abruft
Eine JSON-Statuszusammenfassung pro Statusseite, höchstens einmal pro Minute. Er crawlt nicht, folgt keinen Links aus diesem Dokument heraus und sendet nichts ein.
Bedingte Anfragen
Sobald wir einen Validator halten, tragen spätere Anfragen If-None-Match und If-Modified-Since. Eine unveränderte Seite antwortet dann mit 304 und ohne Body.
Wiederholungen
Keine innerhalb eines Zyklus. Eine fehlgeschlagene Anfrage gilt als fehlgeschlagen, und wir warten auf die nächste Minute, statt eine angeschlagene Seite weiter zu bedrängen.
Weiterleitungen
Werden nicht verfolgt. Ein 3xx gilt als Fehlschlag, so kann uns niemand auf einen Host lenken, den nie jemand geprüft hat.
Antwortgröße
Gedeckelt auf 2 MB, geprüft während die Bytes eintreffen, nicht erst nachdem der ganze Body gepuffert wurde.
Befolgt robots.txt
Nein. Blockier ihn an deiner Edge, dann hört er sofort auf, ganz ohne Anfrage bei uns.
Quelladressen
Dieselbe veröffentlichte Flotte, aus der auch die Monitoring-Checks laufen.
uptimeify.io/ips.txt

UptimeifyToolsBot

Eine Anfrage, auf Zuruf
User-Agent
UptimeifyToolsBot/1.0 (+https://uptimeify.io/robot)

Kommt von den kostenlosen Tools und von den anonymen Checks, die unser MCP-Server für KI-Agenten bereitstellt.

Was er tut
Ruft eine Adresse ab, die jemand in eines unserer kostenlosen Tools getippt oder ein KI-Agent an unseren MCP-Server übergeben hat, und meldet zurück, was ankam.
Häufigkeit
Gar kein Zeitplan. Eine Anfrage pro Anfrage, und Rate-Limits pro IP begrenzen auf unserer Seite, wie schnell das jemand wiederholen kann.
Befolgt robots.txt
Nein. Er handelt für einen Menschen, der auf eine Antwort wartet, so wie es ein Browser tut, wenn dieser Mensch die Adresse selbst öffnet.
Quelladressen
Unsere Anwendungsserver, nicht die Monitoring-Flotte. Diese Adressen stehen deshalb nicht in der Allowlist.

Bis zum 12.08.2026 hat dieser Client eine URL auf einer Domain beworben, die uns nicht gehört. Wenn du ihr aus einem alten Log-Eintrag gefolgt bist und nichts vorgefunden hast: Das war der Grund, und hierhin zeigt sie jetzt.

Adressen und Verifizierung

Jeder geplante Check kommt aus einer festen, veröffentlichten Flotte. Die Liste unten wird aus den Knoten erzeugt, die gerade tatsächlich aktiv sind, nicht aus einer handgepflegten Kopie. Eine Allowlist, die darauf aufbaut, bleibt also richtig, wenn sich die Flotte ändert.

IPv4-Adressen 18

  • 31.70.128.249
  • 37.27.11.231
  • 46.224.9.105
  • 46.224.48.13
  • 46.224.134.214
  • 51.68.147.37
  • 51.83.224.155
  • 57.130.70.240
  • 57.130.71.227
  • 57.131.17.27
  • 57.131.18.139
  • 57.131.135.75
  • 57.131.135.216
  • 85.215.171.190
  • 85.215.239.242
  • 91.98.235.124
  • 93.93.119.216
  • 95.217.180.92

IPv6-Adressen 14

  • 2001:41d0:601:2000::13f0
  • 2001:41d0:601:2000::402
  • 2001:41d0:701:1000::144d
  • 2001:41d0:701:1000::9d8
  • 2001:ba0:209:1e00::1
  • 2001:ba0:209:1e00:1::1
  • 2a01:239:482:2900::1
  • 2a01:239:482:2900:1::1
  • 2a01:4f8:1c1a:5fe9::1
  • 2a01:4f8:1c1a:ede::1
  • 2a01:4f8:c012:cd67::1
  • 2a01:4f8:c013:9515::1
  • 2a01:4f9:c013:d0db::1
  • 2a01:4f9:c013:d85d::1

Fertige Firewall-Snippets pro Anbieter stehen in der Firewall-Dokumentation. Wenn du es lieber automatisierst: /ips.txt ist reiner Text, eine Adresse pro Zeile, fünf Minuten gecacht.

Prüfen, ob wir durchkommen

Wenn schon eine Regel steht und du wissen willst, was sie mit uns macht: Lass uns dich abrufen. Wir fragen die Adresse mit dem User-Agent von SiteMonitorBot an und zeigen dir die Antwort, die dein eigener Server gibt.

Lass uns dich abrufen

Wir rufen die eingegebene Adresse mit dem User-Agent von SiteMonitorBot ab und zeigen dir die Antwort deines Servers. Mehr wird nicht nachgeschlagen.

Das fragt deinen Server und liest seine Antwort, mehr nicht. Es verrät nicht, ob diese Adresse bei uns überwacht wird, von wem oder wie oft. Das wäre eine Auskunft über fremde Konten an jeden, der einen Hostnamen erraten kann.

Warum das in deinem Log steht

Was du siehst

SiteMonitorBot/1.0 in gleichmäßigem Takt

Was es ist

Ein Monitor, den jemand auf deiner Seite eingerichtet hat.

Was zu tun ist

Erst intern fragen, dann blockieren. Blockieren lässt ihn Alarm schlagen.

Was du siehst

Ein Chrome-User-Agent, der auf SiteMonitorBot/1.0 endet, dazu mehrere Anfragen samt Assets

Was es ist

Ein Screenshot- oder Playwright-Monitor.

Was zu tun ist

Gleiche Herkunft, gleicher Auftraggeber. Behandle ihn wie den Monitor oben.

Was du siehst

Gewöhnliches Desktop-Chrome, aus einer Adresse in /ips.txt

Was es ist

Ein Keyword- oder Expected-Response-Check.

Was zu tun ist

Ein Name-Match greift nicht. Match auf die Adresse.

Was du siehst

UptimeifyStatusBot holt sich /api/v2/summary.json bis zu einmal pro Minute

Was es ist

Wir lesen deine öffentliche Statusseite.

Was zu tun ist

Unerwünscht? An der Edge blockieren. Sonst wird nichts von dir gelesen.

Was du siehst

Eine einzelne Anfrage von UptimeifyToolsBot ohne erkennbares Muster

Was es ist

Jemand hat ein kostenloses Tool benutzt, oder ein KI-Agent hat unseren MCP-Server aufgerufen.

Was zu tun ist

Da folgt nichts nach. Dahinter steht kein Zeitplan.

Woran wir uns halten

Unsere Checks laufen gegen Infrastruktur, die uns nicht gehört. Da zählen die Grenzen mehr als die Absichten. Diese hier stehen im Code, nicht im Leitbild:

  • Wir weisen uns aus. Jede geplante Anfrage trägt einen Namen und eine URL, die auf diese Seite führt. Die eine Ausnahme, die Keyword- und Expected-Response-Checks, steht oben benannt, statt dass du sie selbst herausfinden musst.
  • Wir gehen zurück, statt zu wiederholen. Ein fehlgeschlagener Statusseiten-Abruf wartet auf den nächsten Zyklus. Er bedrängt keinen Host, der ohnehin schon kämpft.
  • Wir fragen so wenig ab wie möglich. Bedingte Anfragen heißen: Eine unveränderte Statusseite antwortet mit HTTP-Statuscode 304 und schickt gar keinen Body. Erreichbarkeitsprüfungen lesen von vornherein keinen.
  • Wir bleiben, wo wir hingeschickt wurden. Eine Weiterleitung beim Statusseiten-Abruf ist ein Fehlschlag, keine Einladung. Nichts entscheidet zur Laufzeit, einen ungeprüften Host abzurufen.
  • Wir veröffentlichen, woher wir kommen. Die Adressliste oben entsteht aus der laufenden Flotte. Blockieren oder Freigeben hängt also nie daran, dass wir daran denken, eine Seite zu aktualisieren.

Was wir nicht tun: robots.txt lesen. Ein Disallow kostet dich zehn Minuten und ändert bei keinem der drei Clients etwas. Eine Regel an deinem CDN, deiner WAF oder deinem Webserver wirkt sofort.

Uns blockieren

Match auf die Teilzeichenkette, nie auf den ganzen User-Agent-String, und die Anfrage abweisen. Cloudflare, als Ausdruck einer eigenen WAF-Regel:

(http.user_agent contains "SiteMonitorBot") or
(http.user_agent contains "UptimeifyStatusBot") or
(http.user_agent contains "UptimeifyToolsBot")

nginx:

if ($http_user_agent ~* "(SiteMonitorBot|UptimeifyStatusBot|UptimeifyToolsBot)") {
    return 403;
}

Apache 2.4:

<If "%{HTTP_USER_AGENT} =~ /SiteMonitorBot|UptimeifyStatusBot|UptimeifyToolsBot/">
    Require all denied
</If>

Wenn du auch die Keyword- und Expected-Response-Checks stoppen willst, blockiere die Adressen aus /ips.txt statt der Namen, diese Anfragen tragen einen gewöhnlichen Chrome-User-Agent.

Eine Folge solltest du vorher abwägen: Wenn du SiteMonitorBot blockierst, stoppt das einen Check, auf den sich jemand in deinem eigenen Team verlässt, und er meldet dann einen Fehlalarm, einen Ausfall, der nicht stattfindet. Auch deshalb sind es drei getrennte Clients statt einem: Das Blockieren des einen darf die anderen nie stillschweigend mitnehmen.

Kontakt

Etwas stimmt nicht, ist zu häufig oder schlicht unerwünscht: hello@uptimeify.io. Wir lesen diese Adresse und antworten.