InfraNestInfraNest

Monitoring & Status

Erfahre vom Ausfall, bevor deine Kunden ihn bemerken

Überwache Websites, APIs, Ports, Zertifikate, DNS, Cronjobs und deine eigenen Server — gleichzeitig geprüft von Europa, Nordamerika und Asien-Pazifik aus, damit du die Störung siehst, die deine Kunden in Frankfurt trifft, auch wenn von Ashburn aus alles in Ordnung wirkt. Ein Status wechselt erst, wenn genug Regionen übereinstimmen — deshalb hörst du von uns, wenn wirklich etwas nicht stimmt.

Free-Tarif · Keine Kreditkarte · Erster Monitor in unter einer Minute live

  • Von drei Kontinenten aus geprüft
  • Ein Vorfall, nicht zehn Warnungen
  • Elf Dinge, die es überwachen kann
  • Direkt an Slack, Jira oder PagerDuty
MonitoreÜberwache alles mit einer Adresse, von überall aus.+ Monitor hinzufügen
MonitorLetzte 24 StundenUptime
API healthHTTPUp · HTTP 200 — OK100.0%
App — northwind-app.devHTTPUp · HTTP 200 — OK100.0%
Checkout flowHTTPDown · HTTP 503 — Service Unavailable96.9%
DocsHTTPUp · HTTP 200 — OK100.0%
Mail — SMTPPortUp · Connected in 24 ms100.0%
Marketing siteHTTPUp · HTTP 200 — OK100.0%
6 von 12 Monitoren angezeigt
Search APIAPIBeeinträchtigt · HTTP 200 — OK, but the response-time assertion failed (1,240 ms)100.0%
API healthHTTPUp · HTTP 200 — OK100.0%
App — northwind-app.devHTTPUp · HTTP 200 — OK100.0%
Checkout flowHTTPDown · HTTP 503 — Service Unavailable96.9%
DocsHTTPUp · HTTP 200 — OK100.0%
Marketing siteHTTPUp · HTTP 200 — OK100.0%
Staging appHTTPUnbekannt ·
Signup page copyKeywordUp · HTTP 200 — OK100.0%
Mail — SMTPPortUp · Connected in 24 ms100.0%
Postgres — db-01PortUp · Connected in 24 ms100.0%
www → apex redirectRedirectUp · HTTP 200 — OK100.0%
northwind.com certificateSSLUp · Valid — 74 days remaining100.0%

Von überall geprüft, bestätigt, bevor du geweckt wirst

Jede Prüfung läuft gleichzeitig von Probes in Europa, Nordamerika und Asien-Pazifik. Fällt eine aus, ist das keine Störung — das ist eine Probe mit einer schlechten Sekunde, und ein Monitoring-Tool, das dich dafür anpiept, erzieht dich dazu, es zu ignorieren. Ein Status kippt also erst, wenn genug Probes in genug verschiedenen Regionen übereinstimmen. Du bekommst die Störung, die deine Kunden wirklich trifft — und die, die sie nie bemerkt haben, bekommst du nicht mehr.

  • Probes in Europa, Nordamerika und Asien-Pazifik, bei jeder Prüfung
  • Ein Status wechselt erst, wenn dein Schwellwert an Probes — und an Regionen — übereinstimmt
  • Antwortzeiten je Region, damit „in Asien ist es langsam“ etwas ist, das man sehen kann
  • Flattern wird gedämpft, damit ein springender Dienst dich nicht zwölfmal anpiept
Search API

https://api.northwind.com/v1/search

Geprüft aus 3 Regionen · 2 Probes müssen zustimmen · 2 von 3 Regionen müssen zustimmen

Europawidersprach
NordamerikaHTTP 200 — OK, but the response-time assertion failed (1,240 ms)
Asien-PazifikHTTP 200 — OK, but the response-time assertion failed (1,240 ms)

Ein Status wechselt erst, wenn die Schwellen oben erreicht sind — deshalb erreicht dich eine Region mit einer schlechten Sekunde nie.

Elf Dinge, die es überwachen kann — nicht nur „läuft die Seite“

Eine Website, die 200 antwortet, ist der einfache Fall. InfraNest überwacht auch das, was leise kaputtgeht: einen Cronjob, der sich nicht mehr meldet, eine API, die das falsche JSON-Feld zurückgibt, eine Weiterleitung ohne Ziel, ein Zertifikat drei Tage vor Ablauf, einen geschlossenen Port, einen DNS-Eintrag, der nicht mehr auflöst — und die Server darunter, mit CPU, Speicher, Platte und Diensten vom Agenten. Es beobachtet sogar fremde Statusseiten, damit die Störung eines Providers, von dem du abhängst, dich erreicht, ohne dass du dessen Seite neu lädst.

  • Heartbeat-Monitore fangen den Cronjob, der unbemerkt aufgehört hat
  • API-Monitore prüfen JSON-Felder, nicht nur den Statuscode
  • Server-Monitore melden CPU, Speicher, Platte, Load und Dienste
  • Dienststatus-Monitore fragen die Statusseiten deiner Provider für dich ab
Was möchtest du überwachen?11 Typen

Danach wird gefragt nach

Eine URL und den Statuscode, den du zurückerwartest

Eine URL und das Wort, das in der Antwort stehen soll

Eine URL und die End-URL, auf der du landen willst

Eine Domain oder IP und den Port

Eine Domain und wie viele Tage im Voraus gewarnt werden soll

Eine Domain, den Eintragstyp und den erwarteten Wert

Eine Domain oder IP-Adresse

Eine URL plus Assertions auf das zurückkommende JSON

Nichts — du bekommst eine URL, die dein Job aufruft

Welchen Server und welche Metrik welchen Schwellwert überschreitet

Welchen Provider und welche seiner Komponenten du nutzt

Eine Störung, ein Vorfall — nicht zehn Warnungen

Wenn die Datenbank ausfällt, fällt alles davor mit aus. Die meisten Tools piepen dich dann einmal pro Prüfung an, und du verbringst die ersten zehn Minuten einer Störung damit, herauszufinden, welche Warnung zählt. Sag InfraNest, welche Monitore von welchen abhängen, und es tut das für dich: Fällt der Elternteil aus, werden die Kinder unterdrückt, du bekommst also einen Vorfall, der benennt, was wirklich kaputt ist, mit einer Zeitachse, an die du Updates hängst. Geplante Arbeiten kommen in ein Wartungsfenster und lesen sich nie wie eine Störung.

  • Erkläre, was von was abhängt — ein ausfallender Elternteil legt seine Kinder still
  • Ein Vorfall mit Zeitachse: erkannt, bestätigt, aktualisiert, behoben
  • Wartungsfenster pausieren die Warnungen und markieren die Arbeit als geplant
  • Bestätigen oder beheben direkt aus der Warnung — oder aus einer Automatisierung
Titel
Checkout flow ist down
Monitor ansehenPostmortem schreiben
DauerLäuft noch
MonitorCheckout flow
UrsacheHTTP 503 — Service Unavailable
BenachrichtigtSlack, PagerDuty
Auswirkung
Status
Erkannt14:02Identifiziert14:053Beobachtungjetzt4Behoben
Verlauf
BeobachtungJasparDer Failover auf das Standby-System ist durch. Wir beobachten die Fehlerraten, bevor wir es abschließen.
IdentifiziertJasparDie primäre Datenbank nimmt keine Verbindungen mehr an. Alles davor ist betroffen.
UntersuchungSystemHTTP 503 — Service Unavailable
2 Monitore davon stillgelegt
API healthmit aufgenommen, nicht separat gemeldet
Search APImit aufgenommen, nicht separat gemeldet

Welche Monitore von welchen abhängen, legst du einmal pro Monitor fest.

Wohin die Warnung geht, ist der ganze Punkt

Eine Warnung, die niemand sieht, ist kein Monitoring. Schick Hinweise in einen Slack-Kanal und harte Ausfälle an PagerDuty, daneben E-Mail, Teams, Discord oder Telegram — und stell ein Ziel auf „nur kritisch“, damit das Telefon um 3 Uhr nachts still bleibt für Dinge, die bis Montag warten können. Jenseits der Kanäle kann eine Automatisierung auf die Warnung reagieren, statt sie nur weiterzuleiten: das Jira- oder Linear-Ticket öffnen, das GitHub-Issue anlegen, auf deiner Statusseite posten, an deinen eigenen Endpunkt POSTen oder den Server neu starten und den Vorfall schließen, wenn er zurückkommt.

  • E-Mail, Slack, Teams, Discord, Telegram und PagerDuty
  • Schweregrad je Ziel, damit „nur kritisch“-Kanäle sonst still bleiben
  • Erholungsmeldungen, damit „läuft es wieder?“ beantwortet ist, ohne zu fragen
  • Oder gib es an eine Automatisierung: Jira, Linear, Notion, GitHub, ein Webhook, ein Neustart
Diesen Zielen Bescheid gebenJedes Ziel hört, was du es hören lässt.

Oder eine Automatisierung darauf reagieren lassen

Jira-Ticket anlegenLinear-Issue öffnenGitHub-Issue anlegenStatusseiten-Meldung postenWebhook aufrufenServer neu starten

Was es sonst noch erledigt

Die Teile, die erst interessant werden, wenn du sie brauchst.

Statusseiten

Mach aus dem, was du ohnehin überwachst, eine gebrandete öffentliche Seite auf deiner eigenen Domain — mit den Vorfällen und Wartungsfenstern, die automatisch mitgehen.

Deine eigenen Probes

Betreibe eine Probe auf einem deiner eigenen Server, um etwas zu überwachen, das nur aus deinem Netz erreichbar ist — neben den öffentlichen.

Verlauf der Antwortzeiten

Antwortzeiten je Region über die Zeit aufbewahrt, damit „letzten Dienstag wurde es langsamer“ etwas ist, worauf man zeigen kann, statt es zu erinnern.

Warnungen auf Servermetriken

Warne, wenn CPU, Platte oder Netzwerk eines Servers eine Schwelle überschreiten — bevor daraus eine Prüfung wird, die scheitert.

Wartungsfenster

Plane die Arbeit, und die Warnungen, die Statusseite und die Uptime-Zahl verstehen alle drei, dass es geplant war.

Automatisierungen auf Monitoren

Einen Monitor pausieren, ihn eine Stunde stummschalten, ein Fenster öffnen oder einen Server neu starten — ausgelöst von, was immer du willst.

Erster Monitor in unter einer Minute live

Füge eine URL ein. Kein Agent zu installieren, nichts zu konfigurieren, und der Free-Tarif behält zwanzig davon.

Selbst gebaut vs InfraNest

Der Unterschied zwischen zu wissen, dass etwas ausgefallen ist, und zu erfahren, was zählt.

Von Hand

  • Ein Cronjob, der eine URL von einer Maschine in einem Land curlt
  • Jeder abhängige Dienst piept dich für einen einzigen Ausfall separat an
  • Warnungen in einem Postfach, das um 3 Uhr nachts niemand liest
  • Ein Cronjob, der unbemerkt aufhörte und eine Woche später auffiel
  • Geplante Arbeiten, nicht von einer echten Störung zu unterscheiden

Mit InfraNest

  • Probes auf drei Kontinenten, die übereinstimmen müssen, bevor du etwas hörst
  • Ein Vorfall, der benennt, was wirklich kaputt ist
  • Hinweise an Slack, harte Ausfälle an PagerDuty, „nur kritisch“, wo es zählt
  • Ein Heartbeat-Monitor, der die Stille binnen Minuten bemerkt
  • Wartungsfenster, die die Uptime-Zahl ehrlich halten

Ein Login, zehn Module

Jedes Modul steckt in jedem Plan, auch in Free — nur die Limits unterscheiden sich.

Was es einzeln kosten würde

Jedes Teil aus einem anderen Tool – das summiert sich schnell:

Domain & DNS
~30 €
Uptime-Monitoring
~29 €
SSL-Tracking
~15 €
Statusseite
~29 €
Server-Panel
~15 €
Über 4–5 einzelne Tools
100–150 €/Mon.
InfraNest Business – alles davon, ein Login49 €/Mon.

Alle Funktionen vergleichen →

Häufige Fragen

Von wo laufen die Prüfungen?

Von Probes in Europa, Nordamerika und Asien-Pazifik. Jede Prüfung läuft von mehreren gleichzeitig, und ein Status wechselt erst, wenn genug davon — über genug Regionen verteilt — übereinstimmen; genau das verhindert, dass ein wackliger Standort dich anpiept. Du kannst auch eine Probe auf deinem eigenen Server betreiben, um etwas zu überwachen, das nur aus deinem Netz erreichbar ist.

Was kann es überwachen?

Websites und APIs über HTTP, Keyword- und Weiterleitungsprüfungen, TCP-Ports, Ping, DNS-Einträge, SSL-Zertifikate, Heartbeat-Monitore für Cronjobs, API-Monitore mit JSON-Prüfungen, CPU, Speicher, Platte und Dienste deiner Server sowie die Statusseiten anderer Anbieter.

Wie verhindere ich, dass eine Störung mich zehnmal anpiept?

Sag InfraNest, welche Monitore von welchen abhängen. Fällt ein Elternteil aus, werden seine Kinder unterdrückt, du bekommst also einen Vorfall, der die Ursache benennt, statt einer Warnung pro betroffener Prüfung. Flattern wird separat gedämpft, damit ein auf und ab springender Dienst dich nicht jedes Mal anpiept.

Wohin können Warnungen gehen?

E-Mail, Slack, Microsoft Teams, Discord, Telegram und PagerDuty, und jedes Ziel lässt sich auf einen Schweregrad stellen — ein „nur kritisch“-Kanal bleibt bei Hinweisen also still. Eine Automatisierung kann weitergehen und ein Jira-, Linear-, Notion- oder GitHub-Ticket öffnen, auf deiner Statusseite posten, deinen eigenen Webhook aufrufen oder direkt am Server eingreifen.

Braucht die Überwachung eines Cronjobs einen Agenten?

Nein. Ein Heartbeat-Monitor gibt dir eine URL, die dein Skript oder Cron aufruft, wenn es fertig ist. Kommt der Aufruf nicht im Fenster an, das du gesetzt hast, wirst du gewarnt — und das fängt den Job, der unbemerkt aufhörte, den Ausfall, den eine URL-Prüfung nie sehen kann.

Was passiert bei geplanter Wartung?

Öffne ein Wartungsfenster, und die Prüfungen darin warnen nicht mehr, die Statusseite sagt, dass die Arbeit geplant war, und deine Uptime-Zahl wird dafür nicht bestraft.

Zwanzig Monitore im kostenlosen Plan

Füge eine URL ein und beobachte sie von drei Kontinenten aus.

Kostenloser Plan · Keine Kreditkarte nötig · In Minuten eingerichtet