# 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.

Source: https://uptimeify.io/de/robot

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

Vom Betreiber bestellt
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.
no
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.

Liest öffentliche Statusseiten
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.
no
Quelladressen
Dieselbe veröffentlichte Flotte, aus der auch die Monitoring-Checks laufen.
uptimeify.io/ips.txt

Eine Anfrage, auf Zuruf
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.
no
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.

Fertige Firewall-Snippets pro Anbieter stehen in der [Firewall-Dokumentation](https://docs.uptimeify.io/docs/integrations/firewall). 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.

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
Was es ist
Was zu tun ist
`SiteMonitorBot/1.0` in gleichmäßigem Takt
Ein Monitor, den jemand auf deiner Seite eingerichtet hat.
Erst intern fragen, dann blockieren. Blockieren lässt ihn Alarm schlagen.
Ein Chrome-User-Agent, der auf `SiteMonitorBot/1.0` endet, dazu mehrere Anfragen samt Assets
Ein Screenshot- oder Playwright-Monitor.
Gleiche Herkunft, gleicher Auftraggeber. Behandle ihn wie den Monitor oben.
Gewöhnliches Desktop-Chrome, aus einer Adresse in `/ips.txt`
Ein Keyword- oder Expected-Response-Check.
Ein Name-Match greift nicht. Match auf die Adresse.
`UptimeifyStatusBot` holt sich `/api/v2/summary.json` bis zu einmal pro Minute
Wir lesen deine öffentliche Statusseite.
Unerwünscht? An der Edge blockieren. Sonst wird nichts von dir gelesen.
Eine einzelne Anfrage von `UptimeifyToolsBot` ohne erkennbares Muster
Jemand hat ein kostenloses Tool benutzt, oder ein KI-Agent hat unseren MCP-Server aufgerufen.
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:

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

Apache 2.4:

```apache
<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](mailto:hello@uptimeify.io). Wir lesen diese Adresse und antworten.