Uptime-Monitoring
Erkennen Sie Ausfälle sofort, aus mehreren Regionen, bevor Ihre Kunden etwas merken.
Synthetisches MonitoringWeb Vitals bei jedem Lauf Echte Klickwege,
Echte Klickwege,
per Playwright.
Synthetisches Monitoring für Journeys, die Umsatz bringen: Ihre Playwright-Skripte melden sich an und bezahlen alle 5 Minuten in einem echten Browser. Ein Fehler wird vor jedem Alarm erneut geprüft.
14 Tage kostenlos testen, ein Browser-Check inklusive. Keine Kreditkarte nötig.
Teams vertrauen auf Hyperping, wenn Uptime an erster Stelle steht.
Erfolgsgeschichten lesen
Was ist synthetisches Monitoring? Ein Testnutzer, der nie schläft.
Synthetisches Monitoring führt nach Zeitplan geskriptete Besuche Ihrer Website oder API aus, von außerhalb Ihrer Infrastruktur, und alarmiert Sie, wenn ein Schritt fehlschlägt. Es findet einen kaputten Login oder Checkout vor dem ersten Kunden, auch wenn gerade niemand die Seite besucht.
Uptime-Check: fragt den Server
Sendet alle 30 Sekunden eine Anfrage und liest Statuscode, Antwortzeit und ein Schlüsselwort. Schnell und günstig, aber ein Login-Button, der nicht mehr funktioniert, antwortet trotzdem mit 200.
Uptime-MonitoringSynthetischer Check: benutzt die Website
Öffnet die Seite in einem echten Browser, führt ihr JavaScript aus, klickt, tippt und prüft, was erscheint, wie ein Nutzer. So fallen kaputte Logins, Checkouts und leer bleibende Seiten auf.
Browser-ChecksReal User Monitoring: wartet auf Besucher
Misst, was echte Besucher erleben, sieht ein Problem also erst, wenn jemand darauf gestoßen ist, und um 3 Uhr nachts ohne Traffic gar nichts. Synthetische Checks laufen nach Zeitplan, ob jemand die Seite besucht oder nicht.
Synthetisches Transaktionsmonitoring. Für die Abläufe, die Umsatz bringen.
Ein Browser-Check geht eine ganze User Journey Schritt für Schritt durch und schlägt bei dem Schritt fehl, der kaputt ist. Diese prüfen Teams zuerst.
- step 'Sign in' · expect(page).toHaveURL(/dashboard/) failedoutage confirmed from San Francisco
Login und SSO
Ein Wechsel des Identity Providers, ein abgelaufenes Client Secret, eine Weiterleitungsschleife. Der Check meldet sich mit einem Testkonto an und schlägt fehl, wenn das Dashboard nie erscheint.
Einen Auth0-Login überwachen - step 'Pay with test card' · timeout 30000mson-call paged · video and trace attached
Checkout und Zahlung
In den Warenkorb legen, die Adresse ausfüllen, im Zahlungs-iframe mit einer Testkarte bezahlen und auf die Bestätigung warten. Der Ablauf, der zuerst Geld kostet, wird zuerst geprüft.
Einen Stripe-Checkout testen - step 'Create account' · getByText(/check your inbox/) not visiblealert sent · screenshot attached
Registrierung und Onboarding
Legen Sie bei jedem Lauf ein Konto mit einer neuen E-Mail-Adresse an und prüfen Sie den Willkommensbildschirm, damit ein kaputtes Formular oder ein fehlschlagender E-Mail-Schritt Ihr Wachstum nicht still bremst.
E-Mail-Links und OTP testen - page.goto('/pricing') · 200 OK · h1 not visiblecheck failed · console error in the trace
Seiten, die im Browser rendern
Single-Page-Apps und hydrierte Frameworks antworten mit 200 und einer leeren Hülle. Nur ein Browser, der das JavaScript ausführt, sieht den Fehler, der die Seite leer lässt.
Hydration-Fehler erkennen - step 'Search' · product-card count 0check failed at step 'Search'
Suche und Kernfunktionen
Eine Suchanfrage eingeben, auf die Ergebnisse warten, prüfen, dass es welche gibt. Dasselbe gilt für ein Dashboard, das Daten lädt, einen Upload oder einen Download, auf den Ihre Nutzer angewiesen sind.
12 fertige Skripte - POST /v1/auth/token · 200 · GET /v1/orders · 500check failed on the second call
Mehrstufige API-Abläufe
Ein Token holen, an den nächsten Aufruf übergeben und das JSON prüfen, ohne eine Seite zu öffnen. Ein einzelner Endpoint ist als HTTP-Monitor einfacher.
API-Monitoring
Normale Playwright-Tests. Kein Recorder zu lernen, kein Format, aus dem man nicht herauskommt.
Jeder Check ist ein normaler Playwright-Test in TypeScript, ausgeführt auf Node 24 mit Playwright 1.59.1 und gängigen Paketen. Bewahren Sie die Dateien in Ihrem Repository auf und führen Sie sie lokal mit denselben Versionen aus.
- 1
Schreiben Sie einen normalen Playwright-Test
Fügen Sie eine .spec.ts-Datei ein, starten Sie mit einer von 12 Vorlagen oder zeichnen Sie einen Test mit Playwrights Codegen auf. Kein proprietäres Format: Dieselbe Datei läuft auf Ihrem Rechner.
- 2
Halten Sie Secrets aus dem Skript heraus
Testzugangsdaten und API-Tokens gehören in die Umgebungsvariablen des Checks und werden mit process.env gelesen. Gliedern Sie Abschnitte mit test.step(), und jeder wird einzeln gemeldet.
- 3
Einmal ausführen, dann planen
Run testet das Skript direkt im Editor und zeigt jeden Schritt und die Logs. Speichern Sie, und es läuft alle 5 Minuten aus Frankfurt und San Francisco und alarmiert wie jeder andere Monitor.
login.spec.tstypescript
import { test, expect } from '@playwright/test';
test('user can log in', async ({ page }) => {
await test.step('Open the login page', async () => {
await page.goto('https://app.example.com/login');
});
await test.step('Sign in', async () => {
await page.getByLabel('Email').fill(process.env.EMAIL);
await page.getByLabel('Password').fill(process.env.PASSWORD);
await page.getByRole('button', { name: 'Sign in' }).click();
});
await test.step('Dashboard loads', async () => {
await expect(page).toHaveURL(/\/dashboard/);
await expect(page.getByTestId('user-menu')).toBeVisible();
});
});Ein fehlgeschlagener Schritt wird erneut geprüft. Dann sehen Sie genau, was kaputt ist.
Browser-Abläufe sind wackelig: ein langsames Drittanbieter-Skript, ein Netzwerkaussetzer. Ein fehlgeschlagener Lauf wird sofort aus der anderen Region wiederholt, und erst ein zweiter Fehler eröffnet einen Ausfall, mit allem, was Sie zum Debuggen brauchen.
- Geplanter Laufevery 5 min · Frankfurt, then San Francisco
Jeder Lauf führt das ganze Skript in einem frischen Browser aus, abwechselnd aus Frankfurt und San Francisco. Jeder Schritt, jede Logzeile und jeder Web Vital wird gespeichert.
- Fehlgeschlagener Schritt'Pay with test card' · Frankfurt
Eine Assertion, die nicht hält, ein Locator, der nie erscheint, oder ein Lauf, der in ein Timeout läuft. Noch wird nichts gesendet.
- Doppelte Prüfungsame script · San Francisco
Der Lauf wird sofort aus der anderen Region wiederholt. Ein wackeliges Netz oder ein einmaliger Aussetzer besteht dort, und es wird kein Ausfall eröffnet.
- Bestätigtoutage opens · alerts go out
Nur ein Fehler, der sich wiederholt, eröffnet einen Ausfall, alarmiert die Kanäle des Monitors und startet seine Eskalationsrichtlinie.
Schritte
✗ Pay with test card · 30.0sJeder test.step() erscheint im Lauf mit grünem oder rotem Status und seiner Dauer, sodass der Alarm auf den Abschnitt zeigt, der kaputt ist.
Screenshot und Video
failure.png · video.webmAn jeden fehlgeschlagenen Lauf angehängt. Sehen Sie, was der Browser gesehen hat: das Cookie-Banner im Weg, die Fehlermeldung, den Spinner, der nie aufhörte.
Playwright-Trace
trace.zipAn jeden fehlgeschlagenen Lauf angehängt. Spielen Sie ihn Aktion für Aktion nach, mit DOM, Konsole und Netzwerkanfragen bei jedem Schritt.
Logs
TimeoutError: 30000msDie vollständige Ausgabe des Laufs und der Fehler, gespeichert bei jedem Lauf, ob fehlgeschlagen oder nicht.
Core Web Vitals bei jedem Lauf. Ohne eine Zeile zusätzlichen Code.
Jede Seite, die Ihr Skript öffnet, wird beim Laden gemessen. Der Check stellt die fünf Metriken im Zeitverlauf dar und zeigt sie bei jedem Lauf, sodass ein langsames Release neben dem Schritt auftaucht, den es verlangsamt hat.
- LCP≤ 2,500 ms
Largest Contentful Paint
Wie lange es dauert, bis das größte sichtbare Element gerendert ist.
- CLS≤ 0.1
Cumulative Layout Shift
Wie stark das Layout beim Laden springt.
- TBT≤ 200 ms
Total Blocking Time
Wie lange der Main Thread zu beschäftigt war, um auf Eingaben zu reagieren.
- FCP≤ 1,800 ms
First Contentful Paint
Wie lange Nutzer auf einen leeren Bildschirm schauen.
- TTFB≤ 800 ms
Time to First Byte
Wie schnell der Server antwortet, aus jeder Region.
Die Schwellenwerte sind Googles „gute“ Grenzen. INP braucht echte Nutzereingaben, deshalb erfassen synthetische Checks ihn nicht.
Dann erfährt es die richtige Person. Und Ihre Kunden sehen es.
Browser-Checks sind Monitore wie die anderen: dieselben Alarme, Eskalationsrichtlinien und Statusseiten wie Ihre Uptime-, API- und SSL-Checks, in einem Konto.
Die Rufbereitschaft, nicht ein Kanal
Verknüpfen Sie eine Eskalationsrichtlinie mit dem Check: zuerst Slack, dann SMS und ein Anruf bei der Person in Rufbereitschaft, dann die nächste, wenn niemand bestätigt.
Rufbereitschaft und EskalationEine Statusseite, die sich selbst aktualisiert
Fügen Sie den Check als Dienst zu einer Statusseite hinzu, etwa Checkout. Wenn der Ausfall bestätigt ist, sehen Ihre Kunden ihn, und nach der Erholung zeigt die Seite wieder Betriebsbereit.
StatusseitenAlarme dort, wo Ihr Team schon ist
Slack, Microsoft Teams, E-Mail, SMS, Anrufe, PagerDuty oder Opsgenie: Browser-Checks nutzen dieselben Kanäle, Gruppierungen und Stummschaltungen wie Ihre Uptime-Monitore.
Alarmierung
Verifizierte Alarme.Dort, wo Ihr Team arbeitet.
Jeder fehlgeschlagene Browser-Check wird aus einer zweiten Region wiederholt, bevor er die Tools erreicht, die Ihr Team schon nutzt.
Slack
Microsoft Teams
Google Chat
PagerDuty
Opsgenie
Jira Service Management
Discord
Telegram
Mobile App- SMS
- Anruf
- Webhooks
Das sagen Teams über Hyperping.
@hyperping ist wirklich großartig
Hyperping hat bei uns im Unternehmen den Ruf, reaktionsschneller zu sein als Datadog. Benachrichtigungen von Hyperping erhalten wir meist vor denen von Datadog.
Wir haben uns für Hyperping entschieden, um unseren Nutzern ein hochwertiges Dashboard für Incidents und Statusmeldungen zu bieten.
Die Echtzeit-Alarme von Hyperping sagen uns, wenn die App ausfällt. Manchmal kommen sie sogar, bevor AWS es bemerkt oder uns benachrichtigt.
Wir können uns nicht mehr vorstellen, unser SaaS-Geschäft ohne Hyperping zu betreiben.
Hyperping überzeugt auf ganzer Linie: von der reibungslosen Einrichtung über die Gewissheit, dass alles läuft, bis zum aufmerksamen Kundenservice.
Vom Ausfall Ihrer Website erfahren Sie erst durch das Support-Ticket eines Kunden.
Uptime, Statusseiten, Rufbereitschaft.Eine Plattform. Wissen, bevor Ihre Kunden es merken.
Server-Monitoring
Ein schlanker Agent überwacht CPU, Speicher und Festplatte, damit Sie Probleme erkennen, bevor daraus ein Ausfall wird.
Browser-Checks / E2E
Playwright-Tests, die fehlerhafte Logins und Checkouts finden, bevor Ihre Kunden es tun.
Cron-Job-Monitoring
Alarm, sobald ein Backup oder geplanter Job unbemerkt ausbleibt, nicht erst Tage später.
api.acme.com is down. HTTP 503 from Paris, confirmed from Frankfurt and N. Virginia.9:42 AM
Incident published on status.acme.com. 1,240 subscribers notified by email.9:43 AM
api.acme.com is back up. Downtime 4 min 12 s, incident resolved automatically.9:46 AM
View incident
Benachrichtigungskanäle
Alarme erreichen die richtige Person über 
Slack, Teams, SMS oder Anruf, je nachdem, was sie zuverlässig weckt.
SSL-Monitoring
Zertifikate im Blick: Alarme vor dem Ablauf sorgen dafür, dass sich Ihre Kunden immer sicher verbinden.
Bereitschaftskalender
Planen Sie Rotationen, verteilen Sie die Last und sehen Sie, wer Bereitschaft hat. Jeder Incident erreicht die richtige Person zur richtigen Zeit.
Drei Tools. Eine bessere Rechnung.Monitoring, Statusseiten, Rufbereitschaft. Aus einer Hand.
USD · Monatliche Abrechnung für alle Tarife
Der Tool-Mix
Drei Abos, damit alles läuft.
- Pingdom100 Uptime-Checks + 20 erweiterte Checks149 $/Mon.
- StatuspageStartup (öffentlich) + Growth (privat)348 $/Mon.
- PagerDutyProfessional · 10 Nutzer × 25 $250 $/Mon.
Gesamtkosten
747 $/Monat
8.964 $ für 12 MonateAlles vernetzt, von der ersten Prüfung an.
- 1.000 Monitore
- 10 Statusseiten
- 20 Teammitglieder
- Rufbereitschaft & Eskalationen
- Prüfungen alle 20 Sekunden
- Priorisierter Support
Eine Plattform. Ein Abo.
299 $/Monat
3.588 $ für 12 Monate60 % weniger
Preise ansehen Sparen Sie 5.376 $ pro Jahr gegenüber diesem Mix.
Preisquellen & Annahmen
Geprüft am . Alle Beträge in USD; Preise in Landeswährung können abweichen.
- Pingdom Synthetic Monitoring: 149 $/Monat für 100 Uptime-Checks, 20 erweiterte Checks und 350 SMS-Credits. USD-Preis aus unserer Analyse vom 17. August 2026; der Live-Rechner zeigte bei dieser Prüfung EUR an, daher wurde der USD-Preis heute nicht erneut unabhängig verifiziert.
- Statuspage: eine öffentliche Startup-Seite (99 $/Monat, 1.000 Abonnenten, 10 Teammitglieder) und eine private Growth-Seite (249 $/Monat, 300 authentifizierte Abonnenten, 15 Teammitglieder).
- PagerDuty Professional: 25 $/Nutzer/Monat bei monatlicher Abrechnung, für 10 Nutzer. Der Preis von 21 $ setzt jährliche Abrechnung voraus.
- Hyperping Business: 299 $/Monat bei monatlicher Abrechnung. Die beworbenen 249 $/Monat sind der gerundete Monatswert des Jahrespreises von 2.990 $/Jahr und fließen nicht in diesen Vergleich ein.
Dies ist ein Beispiel für einen Stack aus drei Tools, weder das günstigste mögliche Setup noch ein Vergleich Funktion für Funktion. Pingdom und PagerDuty bieten auch Statusseiten-Funktionen; nicht jedes Team braucht ein separates Statuspage-Abonnement. Nutzungsabhängige Gebühren und kostenpflichtige Konnektoren sind nicht enthalten. Jahressummen entsprechen 12 Monatszahlungen, nicht Angeboten für Jahresabonnements.
Fragen zum synthetischen Monitoring.
Was ist synthetisches Monitoring?
Synthetisches Monitoring führt nach Zeitplan geskriptete Checks gegen Ihre Website oder API aus, von außerhalb Ihrer Infrastruktur, um sicherzustellen, dass wichtige User Journeys noch funktionieren. Es wartet nicht auf echten Traffic: Ein Roboter-Nutzer meldet sich an, sucht oder bezahlt alle paar Minuten und alarmiert Sie, wenn ein Schritt fehlschlägt. Siehe die Definition in unserem Glossar.
Was ist der Unterschied zwischen synthetischem Monitoring und Uptime-Monitoring?
Ein Uptime-Check liest die HTTP-Antwort: Statuscode, Antwortzeit und optional ein Schlüsselwort. Ein synthetischer Browser-Check rendert die Seite und klickt sich durch. Kaputte Logins, Checkouts und JavaScript-Fehler liefern oft trotzdem 200, nur ein Browser-Check sieht sie fehlschlagen. Die meisten Teams nutzen beides: Uptime-Monitoring für jeden Endpoint, Browser-Checks für die wenigen Journeys, die am meisten zählen.
Was ist der Unterschied zwischen synthetischem Monitoring und Real User Monitoring?
Real User Monitoring (RUM) misst, was echte Besucher erleben, braucht also Traffic und meldet Probleme, nachdem Nutzer darauf gestoßen sind. Synthetisches Monitoring spielt dieselbe geskriptete Journey nach Zeitplan ab und erkennt so einen kaputten Ablauf nachts oder vor dem Launch, ganz ohne Besucher. Hyperping macht synthetisches Monitoring, kein RUM.
Was ist synthetisches Transaktionsmonitoring?
Synthetisches Transaktionsmonitoring prüft mehrstufige Abläufe wie Login, Registrierung oder Checkout von Anfang bis Ende statt einer einzelnen Seite. In Hyperping ist jede Transaktion ein Playwright-Skript, und jeder test.step() darin wird mit eigenem Status und eigener Dauer gemeldet, sodass ein Alarm sagt, welcher Schritt kaputt ist. Siehe die Checkout-Vorlage.
Wie funktionieren die Browser-Checks von Hyperping?
Ein Browser-Check führt Ihr Playwright-Skript nach Zeitplan in Headless Chromium aus. Die Standard-Runtime nutzt Node 24 und Playwright 1.59.1 mit gängigen Paketen. Ein Check schlägt fehl, wenn eine Assertion bricht oder der Lauf in ein Timeout läuft, und Secrets wie Testzugangsdaten werden verschlüsselt gespeichert und als Umgebungsvariablen übergeben. Siehe Browser-Checks.
Was passiert, wenn ein Browser-Check fehlschlägt?
Hyperping wiederholt den Lauf sofort aus der anderen Region, was Netzwerkaussetzer und einmalige Ausreißer herausfiltert. Schlägt auch die Wiederholung fehl, wird ein Ausfall eröffnet, und Ihre Alarme und Ihre Eskalationsrichtlinie starten. Jeder Lauf behält seine Schritte und Logs, und fehlgeschlagene Läufe hängen zusätzlich einen Screenshot, ein Video und einen Playwright-Trace an, den Sie Aktion für Aktion nachspielen können.
Misst Hyperping die Core Web Vitals?
Ja. In der aktuellen Runtime erfasst jede Navigation in Ihrem Skript LCP, CLS, TBT, FCP und TTFB ohne zusätzlichen Code. Der Check stellt sie im Zeitverlauf dar und zeigt die Werte jedes Laufs. INP braucht echte Nutzereingaben, deshalb erfassen synthetische Checks ihn nicht.
Kann ich dieselben Playwright-Skripte lokal ausführen?
Ja. Browser-Checks sind normale Playwright-Tests, ohne proprietären Recorder oder eigenes Format. Installieren Sie dieselbe Playwright-Version und dieselben Pakete wie die Runtime, und das Skript verhält sich auf Ihrem Rechner, in der CI und in Hyperping gleich. Siehe lokales Playwright-Setup.
Wie oft laufen Browser-Checks, und wie viele kann ich haben?
Höchstens alle 5 Minuten oder so selten wie einmal am Tag, abwechselnd aus Frankfurt und San Francisco. Essentials enthält 3 Browser-Checks, Pro 10 und Business 25, zusätzlich zu Ihren Uptime-Monitoren, Statusseiten und der Rufbereitschaft; die 14-tägige Testphase enthält einen. Der Free-Plan hat Uptime-Monitore, aber keine Browser-Checks. Siehe Preise.
Welche Tools für synthetisches Monitoring sollte ich vergleichen?
Das hängt davon ab, ob Sie geskriptete Browser-Checks, API-Checks, private Standorte oder auch Real User Monitoring brauchen, und wie viel Sie pro Lauf zahlen wollen. Wir haben 36 Tools in den besten Tools für synthetisches Monitoring verglichen, und Teams, die von Checkly kommen, können Hyperping als Checkly-Alternative lesen.