Synthetische monitoringWeb Vitals bij elke run

Echte klikpaden,
met Playwright.

Synthetische monitoring voor de flows die omzet opleveren: je Playwright-scripts loggen in en rekenen af in een echte browser, elke 5 minuten. Een mislukte stap wordt eerst opnieuw gecontroleerd.

14 dagen gratis, met één browsercheck. Geen creditcard nodig.

Vertrouwd door teams waar uptime op één staat.

Lees klantverhalen

Wat is synthetische monitoring? Een testgebruiker die nooit slaapt.

Synthetische monitoring voert volgens schema gescripte bezoeken aan je site of API uit, van buiten je infrastructuur, en alarmeert je als een stap faalt. Het vindt een kapotte login of checkout vóór de eerste klant, ook als er niemand op de site is.

  • Uptimecheck: vraagt het de server

    Stuurt elke 30 seconden een verzoek en leest de statuscode, de responstijd en een trefwoord. Snel en goedkoop, maar een inlogknop die niet meer werkt, antwoordt nog steeds 200.

    Uptime-monitoring
  • Synthetische check: gebruikt de site

    Opent de pagina in een echte browser, voert het JavaScript uit, klikt, typt en controleert wat er verschijnt, zoals een gebruiker. Zo zie je kapotte logins, checkouts en pagina’s die leeg blijven.

    Browserchecks
  • Real user monitoring: wacht op bezoekers

    Meet wat echte bezoekers ervaren, dus ziet een probleem pas als iemand ertegenaan loopt, en ziet niets om 3 uur ’s nachts zonder verkeer. Synthetische checks draaien volgens schema, of er nu bezoekers zijn of niet.

Synthetische transactiemonitoring. Voor de flows die omzet opleveren.

Een browsercheck doorloopt een hele gebruikersflow, stap voor stap, en faalt op de stap die breekt. Dit zijn de flows die teams als eerste controleren.

  • step 'Sign in' · expect(page).toHaveURL(/dashboard/) failedoutage confirmed from San Francisco

    Login en SSO

    Een andere identity provider, een verlopen client secret, een redirectlus. De check logt in met een testaccount en faalt als het dashboard nooit verschijnt.

    Een Auth0-login monitoren
  • step 'Pay with test card' · timeout 30000mson-call paged · video and trace attached

    Checkout en betaling

    In de winkelwagen leggen, het adres invullen, betalen met een testkaart in het betaal-iframe en wachten op de bevestiging. De flow die als eerste geld kost, controleer je als eerste.

    Een Stripe-checkout testen
  • step 'Create account' · getByText(/check your inbox/) not visiblealert sent · screenshot attached

    Aanmelding en onboarding

    Maak bij elke run een account aan met een nieuw e-mailadres en controleer het welkomstscherm, zodat een kapot formulier of een falende e-mailstap je groei niet stilletjes stopzet.

    E-maillinks en OTP testen
  • page.goto('/pricing') · 200 OK · h1 not visiblecheck failed · console error in the trace

    Pagina’s die in de browser renderen

    Single-page apps en gehydrateerde frameworks antwoorden 200 met een lege schil. Alleen een browser die het JavaScript uitvoert, ziet de fout die de pagina leeg laat.

    Hydratatiefouten opsporen
  • step 'Search' · product-card count 0check failed at step 'Search'

    Zoeken en kernfuncties

    Typ een zoekopdracht, wacht op de resultaten, controleer of die er zijn. Hetzelfde geldt voor een dashboard dat data laadt, een upload of een download waar je gebruikers op rekenen.

    12 kant-en-klare scripts
  • POST /v1/auth/token · 200 · GET /v1/orders · 500check failed on the second call

    API-flows in meerdere stappen

    Haal een token op, geef het door aan de volgende call en controleer de JSON, zonder een pagina te openen. Eén endpoint is eenvoudiger als HTTP-monitor.

    API-monitoring

Gewone Playwright-tests. Geen recorder om te leren, geen formaat om aan vast te zitten.

Elke check is een gewone Playwright-test in TypeScript, uitgevoerd op Node 24 met Playwright 1.59.1 en gangbare packages erbij. Bewaar de bestanden in je repository en draai ze lokaal met dezelfde versies.

  1. 1

    Schrijf een gewone Playwright-test

    Plak een .spec.ts-bestand, begin met een van de 12 templates of neem er een op met Playwrights codegen. Geen eigen formaat: hetzelfde bestand draait op je eigen machine.

  2. 2

    Houd secrets buiten het script

    Testgegevens en API-tokens gaan in de omgevingsvariabelen van de check en worden gelezen met process.env. Verdeel stappen met test.step() en elke stap wordt apart gerapporteerd.

  3. 3

    Eén keer draaien, daarna inplannen

    Run test het script in de editor en toont elke stap en de logs. Sla op, en het draait elke 5 minuten vanuit Frankfurt en San Francisco en alarmeert zoals elke 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();
  });
});

Een mislukte stap wordt opnieuw gecontroleerd. Daarna zie je precies wat er brak.

Browserflows zijn grillig: een traag script van derden, een netwerkhapering. Een mislukte run wordt meteen opnieuw uitgevoerd vanuit de andere regio, en pas een tweede fout opent een storing, met alles wat je nodig hebt om te debuggen.

  1. Geplande runevery 5 min · Frankfurt, then San Francisco

    Elke run voert het hele script uit in een verse browser, om beurten vanuit Frankfurt en San Francisco. Elke stap, logregel en Web Vital wordt bewaard.

  2. Mislukte stap'Pay with test card' · Frankfurt

    Een assertion die niet klopt, een locator die nooit verschijnt, of een run die een time-out krijgt. Er wordt nog niets verstuurd.

  3. Dubbele controlesame script · San Francisco

    De run wordt meteen opnieuw uitgevoerd vanuit de andere regio. Een wankel netwerk of een eenmalige hapering slaagt daar, en er wordt geen storing geopend.

  4. Bevestigdoutage opens · alerts go out

    Alleen een fout die zich herhaalt, opent een storing, alarmeert de kanalen van de monitor en start het escalatiebeleid.

  • Stappen

    ✗ Pay with test card · 30.0s

    Elke test.step() verschijnt in de run met een groene of rode status en de duur, zodat het alarm wijst naar de stap die brak.

  • Screenshot en video

    failure.png · video.webm

    Bij elke mislukte run gevoegd. Zie wat de browser zag: de cookiebanner die in de weg zit, de foutmelding, de spinner die nooit stopte.

  • Playwright-trace

    trace.zip

    Bij elke mislukte run gevoegd. Speel hem actie voor actie af, met de DOM, de console en de netwerkverzoeken bij elke stap.

  • Logs

    TimeoutError: 30000ms

    De volledige uitvoer van de run en de fout, bewaard bij elke run, mislukt of niet.

Core Web Vitals bij elke run. Zonder één regel extra code.

Elke pagina die je script opent, wordt gemeten terwijl hij laadt. De check toont de vijf metrics in de tijd en bij elke run, zodat een trage release opvalt naast de stap die hij vertraagde.

  • LCP≤ 2,500 ms

    Largest Contentful Paint

    Hoe lang het duurt tot het grootste zichtbare element gerenderd is.

  • CLS≤ 0.1

    Cumulative Layout Shift

    Hoeveel de lay-out verspringt tijdens het laden.

  • TBT≤ 200 ms

    Total Blocking Time

    Hoe lang de main thread te druk was om op invoer te reageren.

  • FCP≤ 1,800 ms

    First Contentful Paint

    Hoe lang gebruikers naar een leeg scherm kijken.

  • TTFB≤ 800 ms

    Time to First Byte

    Hoe snel de server antwoordt, vanuit elke regio.

De drempels zijn de ‘goede’ grenzen van Google. INP vraagt echte gebruikersinvoer, dus synthetische checks verzamelen het niet.

Dan hoort de juiste persoon het. En je klanten zien het.

Browserchecks zijn monitors zoals de andere: dezelfde alarmen, escalatiebeleid en statuspagina’s als je uptime-, API- en SSL-checks, in één account.

  • De engineer van piketdienst, niet een kanaal

    Koppel een escalatiebeleid aan de check: eerst Slack, dan sms en een telefoontje naar wie piketdienst heeft, dan de volgende als niemand bevestigt.

    Piketdienst en escalatie
  • Een statuspagina die zichzelf bijwerkt

    Voeg de check als dienst toe aan een statuspagina, zoals Checkout. Zodra de storing bevestigd is, zien je klanten het, en bij herstel gaat de pagina terug naar operationeel.

    Statuspagina’s
  • Alarmen waar je team al zit

    Slack, Microsoft Teams, e-mail, sms, telefoontjes, PagerDuty of Opsgenie: browserchecks gebruiken dezelfde kanalen, groepering en dempingen als je uptimemonitors.

    Meldingen

Geverifieerde meldingen.Precies waar je team werkt.

Elke mislukte browsercheck wordt vanuit een tweede regio opnieuw uitgevoerd voordat hij de tools bereikt die je team al gebruikt.

  • Slack
  • Microsoft Teams
  • Google Chat
  • PagerDuty
  • Opsgenie
  • Jira Service Management
  • Discord
  • Telegram
  • Mobiele app
  • E-mail
  • SMS
  • Telefoon
  • Webhooks

Wat teams zeggen over Hyperping.

Guillermo Rauch
CEO, Vercel
@hyperping is echt geweldig
Fabrice Gregoire
Site Reliability Engineer, Alma
Binnen ons bedrijf staat Hyperping erom bekend dat het sneller reageert dan Datadog. We krijgen meldingen van Hyperping meestal eerder dan van Datadog.
Pierre Renaudin
CTO, Slite
We kozen voor Hyperping om onze gebruikers een hoogwaardig dashboard voor incidenten en statusrapportage te bieden.
Moritz Dausinger
CEO & Founder, Refiner
We krijgen realtime meldingen van Hyperping als de app plat ligt. Die komen soms zelfs binnen voordat AWS het merkt of ons waarschuwt.
Gary Gaspar
CEO & Founder, Marker.io
We kunnen ons niet meer voorstellen dat we ons SaaS-bedrijf zonder Hyperping zouden runnen.
Jakob Bo Storjohann
CEO, Ideanote
Hyperping scoort op alle fronten: van een soepele setup tot gemoedsrust en attente klantenservice.

Je ontdekt pas via een supportticket van een klant dat je site plat ligt.

Uptime, statuspagina’s en piketdienst.Eén platform. Weet het eerder dan je klanten.

Uptime-monitoring

Detecteer downtime zodra het gebeurt, vanuit meerdere regio’s, voordat je klanten het merken.

Servermonitoring

Een lichtgewicht agent volgt CPU, geheugen en schijf, zodat je problemen ziet voordat ze tot downtime leiden.

Browserchecks / E2E

Playwright-tests die kapotte inlog- en afrekenflows opmerken voordat je klanten dat doen.

Cronjob-monitoring

Krijg een melding als een back-up of geplande taak stilletjes niet draait, niet pas dagen later.

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

Meldingskanalen

Meldingen bereiken de juiste persoon via Slack, Teams, SMS of een telefoontje, wat ze ook maar wakker krijgt.

SSL-monitoring

Houd je certificaten onder controle. Krijg een melding voordat ze verlopen, zodat je klanten altijd veilig verbinding maken.

Piketkalender

Plan rotaties, verdeel de werkdruk en zie wie er piketdienst heeft. Elk incident bereikt de juiste persoon op het juiste moment.

Drie tools. Eén lagere rekening.Monitoring, statuspagina’s en piketdienst. Samen.

USD · Maandelijkse facturatie voor elk abonnement

De toolmix

Drie abonnementen om alles draaiende te houden.

Voorbeeldstack
  • Pingdom100 uptimechecks + 20 geavanceerde checks
    US$ 149/mnd
  • StatuspageStartup (openbaar) + Growth (privé)
    US$ 348/mnd
  • PagerDutyProfessional · 10 gebruikers × US$ 25
    US$ 250/mnd
Totale kosten

US$ 747/maand

US$ 8.964 over 12 maanden

Alles verbonden, vanaf de eerste controle.

Business
  • 1.000 monitors
  • 10 statuspagina’s
  • 20 teamleden
  • Piketdienst en escalaties
  • Controles elke 20 seconden
  • Support met voorrang
Eén platform. Eén abonnement.

US$ 299/maand

US$ 3.588 over 12 maanden
60% minder

Bespaar US$ 5.376 per jaar met deze mix.

Bekijk de prijzen
Prijsbronnen en aannames

Gecontroleerd op . Alle bedragen zijn in USD; prijzen in lokale valuta kunnen afwijken.

  • Pingdom Synthetic Monitoring: US$ 149 per maand voor 100 uptimechecks, 20 geavanceerde checks en 350 SMS-credits. Het USD-tarief komt uit onze review van 17 augustus 2026; de live calculator toonde tijdens deze controle EUR, dus het USD-tarief is vandaag niet opnieuw onafhankelijk geverifieerd.
  • Statuspage: één openbare pagina op het Startup-abonnement (US$ 99/maand, 1.000 abonnees, 10 teamleden) en één privépagina op het Growth-abonnement (US$ 249/maand, 300 geauthenticeerde abonnees, 15 teamleden).
  • PagerDuty Professional: US$ 25/gebruiker/maand bij maandelijkse facturatie, voor 10 gebruikers. Het tarief van US$ 21 geldt alleen bij jaarlijkse facturatie.
  • Hyperping Business: US$ 299/maand bij maandelijkse facturatie. De geadverteerde US$ 249/maand is een afgeronde omrekening van US$ 2.990/jaar en wordt in deze vergelijking niet gebruikt.

Dit is één voorbeeld van een stack met drie tools, niet de goedkoopst mogelijke opzet en geen vergelijking functie voor functie. Pingdom en PagerDuty bevatten ook functies voor statuspagina’s; niet elk team heeft een apart Statuspage-abonnement nodig. Gebruikskosten en betaalde connectoren zijn niet meegerekend. Jaartotalen zijn 12 maandbetalingen, geen offertes voor jaarabonnementen.

Vragen over synthetische monitoring.

Wat is synthetische monitoring?

Synthetische monitoring voert volgens schema gescripte checks uit op je website of API, van buiten je infrastructuur, om te controleren dat belangrijke gebruikersflows nog werken. Het wacht niet op echt verkeer: een robotgebruiker logt in, zoekt of rekent af om de paar minuten en alarmeert je als een stap faalt. Zie de definitie in onze woordenlijst.

Wat is het verschil tussen synthetische monitoring en uptimemonitoring?

Een uptimecheck leest het HTTP-antwoord: statuscode, responstijd en optioneel een trefwoord. Een synthetische browsercheck rendert de pagina en klikt er doorheen. Kapotte logins, checkouts en JavaScript-fouten geven vaak nog steeds 200, dus alleen een browsercheck ziet ze falen. De meeste teams gebruiken beide: uptimemonitoring voor elk endpoint, browserchecks voor de paar flows die het meest tellen.

Wat is het verschil tussen synthetische monitoring en real user monitoring?

Real user monitoring (RUM) meet wat echte bezoekers ervaren, heeft dus verkeer nodig en meldt problemen nadat gebruikers ze tegenkwamen. Synthetische monitoring speelt dezelfde gescripte flow volgens schema af, en vangt zo een kapotte flow ’s nachts of voor een lancering, zonder één bezoeker. Hyperping doet synthetische monitoring, geen RUM.

Wat is synthetische transactiemonitoring?

Synthetische transactiemonitoring controleert flows in meerdere stappen, zoals inloggen, aanmelden of afrekenen, van begin tot eind in plaats van één pagina. In Hyperping is elke transactie een Playwright-script, en elke test.step() erin wordt gerapporteerd met een eigen status en duur, zodat een alarm zegt welke stap brak. Zie de checkout-template.

Hoe werken de browserchecks van Hyperping?

Een browsercheck draait je Playwright-script volgens schema in headless Chromium. De standaardruntime gebruikt Node 24 en Playwright 1.59.1 met gangbare packages erbij. Een check faalt als een assertion breekt of de run een time-out krijgt, en secrets zoals testgegevens worden versleuteld opgeslagen en als omgevingsvariabelen doorgegeven. Zie browserchecks.

Wat gebeurt er als een browsercheck faalt?

Hyperping voert de run meteen opnieuw uit vanuit de andere regio, wat netwerkhaperingen en eenmalige uitschieters wegfiltert. Faalt ook die poging, dan wordt een storing geopend en starten je alarmen en je escalatiebeleid. Elke run bewaart zijn stappen en logs, en mislukte runs krijgen ook een screenshot, een video en een Playwright-trace die je actie voor actie kunt afspelen.

Meet Hyperping de Core Web Vitals?

Ja. In de huidige runtime legt elke navigatie in je script LCP, CLS, TBT, FCP en TTFB vast, zonder extra code. De check toont ze in de tijd en geeft de waarden van elke run. INP vraagt echte gebruikersinvoer, dus synthetische checks verzamelen het niet.

Kan ik dezelfde Playwright-scripts lokaal draaien?

Ja. Browserchecks zijn gewone Playwright-tests, zonder eigen recorder of formaat. Installeer dezelfde Playwright-versie en packages als de runtime, en het script gedraagt zich hetzelfde op je eigen machine, in CI en in Hyperping. Zie lokale Playwright-setup.

Hoe vaak draaien browserchecks, en hoeveel kan ik er hebben?

Hooguit elke 5 minuten, of zo weinig als één keer per dag, om beurten vanuit Frankfurt en San Francisco. Essentials bevat 3 browserchecks, Pro 10 en Business 25, naast je uptimemonitors, statuspagina’s en piketdienst; de proefperiode van 14 dagen bevat er één. Het Free-plan heeft uptimemonitors maar geen browserchecks. Zie prijzen.

Welke tools voor synthetische monitoring moet ik vergelijken?

Dat hangt ervan af of je gescripte browserchecks, API-checks, private locaties of ook real user monitoring nodig hebt, en hoeveel je per run wilt betalen. We vergeleken 36 tools in de beste tools voor synthetische monitoring, en teams die van Checkly komen, kunnen Hyperping als Checkly-alternatief lezen.

Je eerste browsercheck, binnen vijf minuten actief.