Uptime monitoring
Catch downtime the moment it happens, from multiple regions, before your customers notice.
Synthetic monitoringWeb Vitals on every run Synthetic checks,
Synthetic checks,
in real Playwright.
Synthetic monitoring for the journeys that make you money. Your Playwright scripts log in, search and check out in a real browser every 5 minutes, and a failed step is checked again before anyone is paged.
14-day free trial with a browser check included. No credit card required.
Trusted by teams that put uptime first.
Read customer storiesWhat is synthetic monitoring? A test user that never sleeps.
Synthetic monitoring runs scripted visits to your site or API on a schedule, from outside your infrastructure, and alerts you when a step fails. It finds a broken login or checkout before the first customer does, even when nobody is visiting.
Uptime check: asks the server
Sends a request every 30 seconds and reads the status code, the response time and a keyword. Fast and cheap, but a login button that stopped working still answers 200.
Uptime monitoringSynthetic check: uses the site
Opens the page in a real browser, runs its JavaScript, clicks, types and checks what appears, like a user would. It catches broken logins, checkouts and pages that render blank.
Browser checksReal user monitoring: waits for visitors
Measures what real visitors experience, so it only sees a problem after someone hits it, and sees nothing at 3 AM with no traffic. Synthetic checks run on a schedule whether anyone visits or not.
Synthetic transaction monitoring. For the flows that bring in revenue.
A browser check walks through a whole user journey, step by step, and fails on the step that breaks. These are the ones teams check first.
- step 'Sign in' · expect(page).toHaveURL(/dashboard/) failedoutage confirmed from San Francisco
Login and SSO
An identity provider change, an expired client secret, a redirect loop. The check signs in with a test account and fails when the dashboard never shows up.
Monitor an Auth0 login - step 'Pay with test card' · timeout 30000mson-call paged · video and trace attached
Checkout and payment
Add to cart, fill the address, pay with a test card inside the payment iframe, and wait for the confirmation. The flow that loses money first is the one to check first.
Test a Stripe checkout - step 'Create account' · getByText(/check your inbox/) not visiblealert sent · screenshot attached
Signup and onboarding
Create an account with a fresh email on every run and check the welcome screen, so a broken form or a failing email step doesn't quietly stop your growth.
Test email links and OTP - page.goto('/pricing') · 200 OK · h1 not visiblecheck failed · console error in the trace
Pages that render in the browser
Single-page apps and hydrated frameworks answer 200 with an empty shell. Only a browser that runs the JavaScript sees the error that leaves the page blank.
Catch hydration errors - step 'Search' · product-card count 0check failed at step 'Search'
Search and key features
Type a query, wait for the results, check there are some. The same goes for a dashboard that loads data, an upload, or a download your users rely on.
12 ready-made scripts - POST /v1/auth/token · 200 · GET /v1/orders · 500check failed on the second call
Multi-step API flows
Fetch a token, pass it to the next call and assert on the JSON, without opening a page. A single endpoint is simpler as an HTTP monitor.
API monitoring
Plain Playwright tests. No recorder to learn, no format to escape.
Each check is a standard Playwright test in TypeScript, run on Node 24 with Playwright 1.59.1 and common packages bundled. Keep the files in your repository and run them locally with the same versions.
- 1
Write a plain Playwright test
Paste a .spec.ts file, start from one of 12 templates, or record one with Playwright’s codegen. No proprietary format: the same file runs on your machine.
- 2
Keep secrets out of the script
Test credentials and API tokens go in the check’s environment variables and are read with process.env. Wrap stages in test.step() and each one is reported on its own.
- 3
Run it once, then schedule it
Run tests the script from the editor and shows each step and the logs. Save, and it runs every 5 minutes from Frankfurt and San Francisco, alerting like any other 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();
});
});A failed step is checked again. Then you see exactly what broke.
Browser flows flake: a slow third-party script, a network hiccup. A failed run is retried at once from the other region, and only a second failure opens an outage, with everything you need to debug it.
- Scheduled runevery 5 min · Frankfurt, then San Francisco
Each run executes the whole script in a fresh browser, from Frankfurt and San Francisco in turn. Every step, log line and Web Vital is kept.
- Failed step'Pay with test card' · Frankfurt
An assertion that doesn’t hold, a locator that never appears, or a run that times out. Nothing is sent yet.
- Double checksame script · San Francisco
The run is retried right away from the other region. A flaky network or a one-off blip passes there, and no outage opens.
- Confirmedoutage opens · alerts go out
Only a failure that happens again opens an outage, alerts the monitor’s channels and starts its escalation policy.
Steps
✗ Pay with test card · 30.0sEvery test.step() shows in the run with a green or red status and its duration, so the alert points at the stage that broke.
Screenshot and video
failure.png · video.webmAttached to every failed run. See what the browser saw: the cookie banner in the way, the error toast, the spinner that never stopped.
Playwright trace
trace.zipAttached to every failed run. Replay it action by action, with the DOM, the console and the network requests at each step.
Logs
TimeoutError: 30000msThe full output of the run and the error, kept with every run, failed or not.
Core Web Vitals on every run. Without a line of extra code.
Each page your script opens is measured as it loads. The check charts the five metrics over time and shows them on every run, so a slow release shows up next to the step it slowed down.
- LCP≤ 2,500 ms
Largest Contentful Paint
How long until the largest visible element renders.
- CLS≤ 0.1
Cumulative Layout Shift
How much the layout jumps around while the page loads.
- TBT≤ 200 ms
Total Blocking Time
How long the main thread was too busy to answer input.
- FCP≤ 1,800 ms
First Contentful Paint
How long users look at a blank screen.
- TTFB≤ 800 ms
Time to First Byte
How fast the server answers, from each region.
Thresholds are Google’s “good” limits. INP needs real user input, so synthetic checks don’t collect it.
Then the right person hears about it. And your customers see it.
Browser checks are monitors like the others: the same alerts, escalation policies and status pages as your uptime, API and SSL checks, in one account.
The on-call engineer, not a channel
Link an escalation policy to the check: Slack first, then SMS and a phone call to whoever is on call, then the next person if nobody acknowledges.
On-call and escalationA status page that updates itself
Add the check to a status page as a service, such as Checkout. When the outage is confirmed, customers see it, and the page goes back to operational on recovery.
Status pagesAlerts where your team already is
Slack, Microsoft Teams, email, SMS, phone calls, PagerDuty or Opsgenie: browser checks use the same channels, grouping and mutes as your uptime monitors.
Alerting
Verified alerts.Where your team works.
Every browser check failure is run again from a second region before it reaches the tools your team already uses.
Slack
Microsoft Teams
Google Chat
PagerDuty
Opsgenie
Jira Service Management
Discord
Telegram
Mobile app
- SMS
- Phone call
- Webhooks
What teams say about Hyperping.
@hyperping is really amazing
Hyperping’s reputation in our company is that it’s more reactive than Datadog. We usually get notifications from Hyperping before Datadog.
We picked Hyperping to bring a high quality incidents and status reporting dashboard to our users.
We have the real-time alerts from Hyperping telling us if the app is down. These are sometimes arriving even before AWS notices or notifies us.
We couldn’t imagine running our SaaS business without Hyperping now.
Hyperping nails all aspects: from smooth setup to peace of mind and attentive customer service.
You learn your site is down from a customer’s support ticket.
Uptime, status pages and on-call.One platform. Know before your customers do.
Server monitoring
A lightweight agent tracks CPU, memory and disk, so you spot trouble before it turns into downtime.
Browser checks / E2E
Playwright tests that catch broken sign-ins and checkouts before your customers do.
Cron job monitoring
Get alerted when a backup or scheduled job silently fails to run, not days 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
Notification channels
Alerts reach the right person on Slack,
Teams, SMS or a phone call, whichever wakes them up.
SSL monitoring
Keep certificates in check. Get alerted before they expire, so your customers always connect securely.
On-call calendar
Plan rotations, share the load, and see who’s on call. Every incident reaches the right person, at the right time.
Three tools. One better bill.Monitoring, status pages, and on-call. Together.
USD · Monthly billing for every plan
The tool mix
Three subscriptions to keep it all running.
- Pingdom100 uptime + 20 advanced checks$149/mo
- StatuspagePublic Startup + private Growth$348/mo
- PagerDutyProfessional · 10 users × $25$250/mo
Combined cost
$747/month
$8,964 over 12 monthsEverything connected, from the first check.
- 1,000 monitors
- 10 status pages
- 20 team members
- On-call & escalations
- 20-second checks
- Priority support
One platform. One subscription.
$299/month
$3,588 over 12 months60% less
Explore pricing Save $5,376 a year with this mix.
Pricing sources & assumptions
Reviewed . All amounts are USD; local currency prices may differ.
- Pingdom Synthetic Monitoring: $149/month for 100 uptime checks, 20 advanced checks and 350 SMS credits. USD rate from our August 17, 2026 review; the live calculator served EUR during this check, so the USD rate was not independently reverified today.
- Statuspage: one public Startup page ($99/month, 1,000 subscribers, 10 team members) and one private Growth page ($249/month, 300 authenticated subscribers, 15 team members).
- PagerDuty Professional: $25/user/month on monthly billing, for 10 users. Its $21 rate requires annual billing.
- Hyperping Business: $299/month on monthly billing. The advertised $249/month is a rounded annual equivalent of $2,990/year and is not used in this comparison.
This is one example of a three-tool stack, not the cheapest possible setup or a feature-for-feature match. Pingdom and PagerDuty also include status-page features; a separate Statuspage subscription may not be needed by every team. Usage charges and paid connectors are not included. Annual totals are 12 monthly payments, not annual subscription quotes.
Questions about synthetic monitoring.
What is synthetic monitoring?
Synthetic monitoring runs scripted checks against your website or API on a schedule, from outside your infrastructure, to make sure key user journeys still work. It doesn’t wait for real traffic: a robot user logs in, searches or checks out every few minutes and alerts you when a step fails. See the definition in our glossary.
What is the difference between synthetic monitoring and uptime monitoring?
An uptime check reads the HTTP response: status code, response time and optionally a keyword. A synthetic browser check renders the page and clicks through it. Broken logins, checkouts and JavaScript errors often still return 200, so only a browser check sees them fail. Most teams use both: uptime monitoring for every endpoint, browser checks for the few journeys that matter most.
What is the difference between synthetic monitoring and real user monitoring?
Real user monitoring (RUM) measures what actual visitors experience, so it needs traffic and reports problems after users hit them. Synthetic monitoring runs the same scripted journey on a schedule, so it catches a broken flow at night or before launch, with zero visitors. Hyperping does synthetic monitoring, not RUM.
What is synthetic transaction monitoring?
Synthetic transaction monitoring checks multi-step flows such as login, signup or checkout end to end, rather than a single page. In Hyperping, each transaction is a Playwright script, and each test.step() in it is reported with its own status and duration, so an alert says which step broke. See the checkout template.
How do Hyperping browser checks work?
A browser check runs your Playwright script in headless Chromium on a schedule. The default runtime uses Node 24 and Playwright 1.59.1 with common packages bundled. A check fails when an assertion breaks or the run times out, and secrets such as test credentials are stored encrypted and passed as environment variables. See browser checks.
What happens when a browser check fails?
Hyperping retries the run right away from the other region, which filters out network blips and one-off flakes. If the retry fails too, an outage opens and your alerts and escalation policy start. Every run keeps its steps and logs, and failed runs also attach a screenshot, a video and a Playwright trace you can replay action by action.
Does Hyperping measure Core Web Vitals?
Yes. On the current runtime, each navigation in your script records LCP, CLS, TBT, FCP and TTFB without any extra code. The check charts them over time and shows the values of every run. INP needs real user input, so synthetic checks don’t collect it.
Can I run the same Playwright scripts locally?
Yes. Browser checks are standard Playwright tests, with no proprietary recorder or format. Install the same Playwright version and packages as the runtime and the script behaves the same on your machine, in CI and in Hyperping. See local Playwright setup.
How often do browser checks run, and how many can I have?
Every 5 minutes at most, or as rarely as once a day, from Frankfurt and San Francisco in turn. Essentials includes 3 browser checks, Pro 10 and Business 25, next to your uptime monitors, status pages and on-call; the 14-day trial includes one. The Free plan has uptime monitors but no browser checks. See pricing.
Which synthetic monitoring tools should I compare?
It depends on whether you need scripted browser checks, API checks, private locations or real user monitoring too, and on how much you want to pay per run. We compared 36 tools in the best synthetic monitoring tools, and teams coming from Checkly can read Hyperping as a Checkly alternative.