Enter submission, and a count assertion on the result grid. Covers the common case where the failure mode is an empty result page rather than an HTTP error.
04-search.spec.tsTS
```typescript
import { test, expect } from '@playwright/test';
test('search returns matching results', async ({ page }) => {
await page.goto('https://example-shop.com');
const box = page.getByPlaceholder('Search products');
await box.fill('running shoes');
await box.press('Enter');
await expect(page).toHaveURL(/q=running\+shoes/);
const results = page.getByTestId('product-card');
await expect(results.first()).toBeVisible();
expect(await results.count()).toBeGreaterThan(0);
});
```
Template 05
### Multi-step checkout
Wraps each stage in `test.step` so the Browser Check run view shows each step as it passes or fails. The step tree gives on-call engineers the exact breakpoint instead of a wall of logs.
05-checkout.spec.tsTS
```typescript
import { test, expect } from '@playwright/test';
test('guest can complete a checkout', async ({ page }) => {
await test.step('open product', async () => {
await page.goto('https://example-shop.com/p/classic-tee');
await expect(page.getByRole('heading', { name: /classic tee/i })).toBeVisible();
});
await test.step('add to cart', async () => {
await page.getByRole('button', { name: 'Add to cart' }).click();
await expect(page.getByTestId('cart-count')).toHaveText('1');
});
await test.step('open cart and checkout', async () => {
await page.getByRole('link', { name: 'Cart' }).click();
await page.getByRole('button', { name: 'Checkout' }).click();
});
await test.step('enter shipping details', async () => {
await page.getByLabel('Email').fill('qa@example.com');
await page.getByLabel('Full name').fill('QA Runner');
await page.getByLabel('Address').fill('1 Test Street');
await page.getByRole('button', { name: 'Continue to payment' }).click();
});
await test.step('confirm order', async () => {
await expect(page.getByText(/order summary/i)).toBeVisible();
});
});
```
Template 06
### API endpoint probe
Uses `page.request` to call a JSON endpoint directly, without rendering HTML. Faster than a UI test and useful for backends you want to check behind Hyperping’s probe regions.
06-api-probe.spec.tsTS
```typescript
import { test, expect } from '@playwright/test';
test('public status API is healthy', async ({ request }) => {
const res = await request.get('https://api.example.com/v1/status', {
headers: { Authorization: `Bearer ${process.env.API_TOKEN}` },
});
expect(res.status()).toBe(200);
expect(res.headers()['content-type']).toContain('application/json');
const body = await res.json();
expect(body).toMatchObject({
status: 'ok',
version: expect.any(String),
});
expect(body.uptime_seconds).toBeGreaterThan(0);
});
```
Template 07
### Broken-link audit
Extracts every nav href, issues HEAD-style GETs, and fails on the first 4xx or 5xx. A lightweight way to catch dead blog links, rotated CDN paths, or accidental release of draft content.
07-broken-links.spec.tsTS
```typescript
import { test, expect } from '@playwright/test';
test('no broken links in the main navigation', async ({ page, request }) => {
await page.goto('https://example.com');
const hrefs = await page.locator('nav a').evaluateAll(
links => links.map(a => a.href).filter(h => h.startsWith('http'))
);
const broken = [];
for (const url of hrefs) {
const res = await request.get(url, { failOnStatusCode: false });
if (res.status() >= 400) broken.push(`${res.status()} ${url}`);
}
expect(broken, `broken links: \n${broken.join('\n')}`).toEqual([]);
});
```
Template 08
### Performance budget
Reads `PerformanceNavigationTiming` from the page and fails when TTFB, DOMContentLoaded, or load exceed a budget. Logs the numbers on every run so you can watch them trend in the run logs.
08-perf-budget.spec.tsTS
```typescript
import { test, expect } from '@playwright/test';
test('homepage meets performance budget', async ({ page }) => {
await page.goto('https://example.com', { waitUntil: 'load' });
const timing = await page.evaluate(() => {
const [nav] = performance.getEntriesByType('navigation');
return {
ttfb: nav.responseStart - nav.requestStart,
domContentLoaded: nav.domContentLoadedEventEnd - nav.startTime,
loadEvent: nav.loadEventEnd - nav.startTime,
};
});
console.log('perf', timing);
expect(timing.ttfb).toBeLessThan(800);
expect(timing.domContentLoaded).toBeLessThan(2500);
expect(timing.loadEvent).toBeLessThan(4000);
});
```
Template 09
### Visual snapshot
Pixel-compares a single critical region against a golden snapshot. Waits for `document.fonts.ready` and disables animations so the diff does not flicker between runs.
09-visual.spec.tsTS
```typescript
import { test, expect } from '@playwright/test';
test('hero section matches golden snapshot', async ({ page }) => {
await page.goto('https://example.com');
await page.evaluate(() => document.fonts.ready);
const hero = page.getByTestId('hero');
await expect(hero).toHaveScreenshot('hero.png', {
maxDiffPixelRatio: 0.02,
animations: 'disabled',
});
});
```
Template 10
### Mobile viewport
Uses Playwright’s `devices` preset to emulate an iPhone, including viewport, user agent, and touch events. Catches responsive regressions that desktop runs never see.
10-mobile.spec.tsTS
```typescript
import { test, expect, devices } from '@playwright/test';
test.use({ ...devices['iPhone 14'] });
test('mobile nav opens and navigates', async ({ page }) => {
await page.goto('https://example.com');
await page.getByRole('button', { name: 'Open menu' }).tap();
await expect(page.getByRole('navigation')).toBeVisible();
await page.getByRole('link', { name: 'Pricing' }).tap();
await expect(page).toHaveURL(/\/pricing/);
});
```
Template 11
### Authenticated via storage state
Injects a session cookie from an environment variable so the check never logs in. Faster, less brittle against auth provider changes, and easier to rotate than a scripted login.
11-storage-state.spec.tsTS
```typescript
import { test, expect } from '@playwright/test';
test.use({
storageState: {
cookies: [
{
name: 'session',
value: process.env.SESSION_COOKIE,
domain: 'app.example.com',
path: '/',
httpOnly: true,
secure: true,
sameSite: 'Lax',
expires: -1,
},
],
origins: [],
},
});
test('dashboard renders for an authenticated user', async ({ page }) => {
await page.goto('https://app.example.com/dashboard');
await expect(page.getByTestId('workspace-name')).toBeVisible();
await expect(page.getByRole('navigation')).toContainText('Settings');
});
```
Template 12
### File download
Waits for the `download` event, inspects the filename, and reads the stream to confirm the file is not empty. Covers invoice, report, and export flows that tend to silently break.
12-download.spec.tsTS
```typescript
import { test, expect } from '@playwright/test';
test('invoice PDF downloads successfully', async ({ page }) => {
await page.goto('https://app.example.com/billing');
const [download] = await Promise.all([
page.waitForEvent('download'),
page.getByRole('button', { name: 'Download latest invoice' }).click(),
]);
expect(download.suggestedFilename()).toMatch(/invoice.*\.pdf$/i);
const stream = await download.createReadStream();
let bytes = 0;
for await (const chunk of stream) bytes += chunk.length;
expect(bytes).toBeGreaterThan(1024);
});
```
## Good habits across every template
- **Prefer role and label locators** over CSS. `getByRole('button', { name: 'Save' })` survives a stylesheet rewrite; `.btn-primary.save` does not.
- **Keep secrets in environment variables.** Reference them with `process.env.NAME` so they never appear in the script body.
- **Stay under the 2-minute global timeout.** Split long journeys into multiple checks rather than one mega-test, or call `test.setTimeout` explicitly.
- **Let the browser settle** before asserting. `await expect(locator).toBeVisible()` already retries, so most `waitForTimeout` calls are unnecessary.
- **Log the values you care about.** A `console.log` for latency, counts, or IDs shows up in run logs and makes post-mortem analysis far easier.
## Next steps
[
Browser Checks→
Runtime versions, timeouts, environment variables, and the run-log format.
](https://hyperping.com/docs/monitoring/browser-checks)[
Local Playwright setup→
Mirror the Hyperping runtime on your machine so scripts behave the same locally and in production.
](https://hyperping.com/docs/monitoring/local-playwright-setup)[
Datacenter regions→
Pick which probe regions run each check to cover the geographies that matter to your users.
](https://hyperping.com/docs/monitoring/datacenter-regions)[
Monitor logs→
Inspect the details of every check Hyperping performs on your monitors.
](https://hyperping.com/docs/monitoring/logs)
For locators, assertions, fixtures, and everything these templates lean on, see the upstream [Playwright docs](https://playwright.dev/docs/writing-tests).
[← Browser Checks](https://hyperping.com/docs/monitoring/browser-checks)[Local Playwright setup →](https://hyperping.com/docs/monitoring/local-playwright-setup)
[](https://x.com/hyperping)[](https://www.linkedin.com/company/hyperping)
© 2026 Hyperping
---
Source: https://hyperping.com/docs/monitoring/browser-checks
# Browser Checks
Updated April 28, 2026
Browser Checks run a Playwright script in headless Chromium on a schedule. The check fails when an assertion breaks or the global timeout fires, and every run keeps logs, screenshots, video, and a Playwright trace for replay. They are Hyperping's implementation of [synthetic monitoring](https://hyperping.com/synthetic-monitoring).
A Browser Check: the Playwright script, Web Vitals, run history, and per-step logs in one view
Default runtime
2026.05 · Node 24 · Playwright 1.59.1
Legacy runtime
2023.04 · Node 16 · Playwright 1.33
Browser
Chromium, headless
Run timeout
2 minutes per run
Test timeout
30 seconds, configurable
Retention
Logs kept indefinitely
> **When to use Browser Checks over an HTTP monitor**
>
> Use a Browser Check when the failure mode is in the rendered page, not the HTTP response. Login flows, search results, multi-step checkouts, and broken JavaScript all return 200 to a plain GET but break for real users.
## Create a browser check
1. Open the dashboard
Go to [app.hyperping.io](https://app.hyperping.io) and click **New monitor**.
2. Pick the Browser protocol
Select **Browser** as the ping protocol and give the monitor a name. Pick the runtime from the runtime card, the default is 2026.05.
3. Write the script and save
Paste a Playwright script into the editor, add any secrets as environment variables, click **Run** to test, then save to schedule the monitor.
## Runtime 2026.05
The 2026.05 runtime is the default for new browser checks. It runs on Node 24 with Playwright 1.59.1 and adds three capabilities on top of the script API.
### What 2026.05 adds 3 features
`Web Vitals`LCP / CLS / TBT / FCP / TTFB
Core Web Vitals are collected from each navigation in your script with no code changes. The dashboard plots them as a time-series chart on the overview, and shows per-run values on every log row.
`Step reporting`test.step()
Every `test.step('...')` call shows up in the run view with a green or red status and its own duration. A failed multi-step check points at the exact stage that broke instead of dropping a wall of logs on the on-call engineer.
`Trace and video`retain-on-failure
Failed runs attach a Playwright trace and a video of the run, alongside the screenshot already captured today. The trace deep-links into [trace.playwright.dev](https://trace.playwright.dev) for step-by-step replay.
### Web Vitals
The runtime injects a `PerformanceObserver` into every page your script opens. After each navigation it captures the five Core Web Vitals and stores them on the run, so you can watch them trend without writing any custom timing code.
**LCP**
≤ 2,500 ms
Largest Contentful Paint. Time to render the largest visible element. High values mean users wait too long before the most useful part of the page loads.
**CLS**
≤ 0.1
Cumulative Layout Shift. Visual stability score. Low values mean the layout doesn't jump around as the page loads.
**TBT**
≤ 200 ms
Total Blocking Time. How long the main thread was blocked from handling user input. High values mean sluggish interactions.
**FCP**
≤ 1,800 ms
First Contentful Paint. Time until any content is rendered. Large values mean users see a white screen for too long.
**TTFB**
≤ 800 ms
Time to First Byte. Server response time for the navigation request. Varies by region and network conditions.
> **Where Web Vitals show up**
>
> The browser-check overview averages each metric across the picked window into a Web Vitals chart, and every log row shows a vitals strip with the snapshot for that single run. Each value is colored against the thresholds above. Runs that never call `page.goto` have nothing to report. FID and INP need real user input and are not collected by synthetic checks.
### Packages available in 2026.05
### Bundled libraries 12 packages
`playwright`1.59.1
Browser automation API.
`@playwright/test`1.59.1
Test runner with fixtures, locators, and expect.
`typescript`^5.6
TypeScript compiler. Use `.spec.ts` files directly.
`expect`^29
Standalone Jest-style assertion library.
`uuid`^9.0.1
RFC4122 UUID generator.
`lodash`4.17.21
Utility functions for arrays, objects, and collections.
`moment`^2.30.1
Date and time parsing, formatting, and arithmetic.
`axios`^1.13.2
HTTP client. Useful for hitting APIs alongside the UI flow.
`btoa`1.2.1
Base64 encoding helper for Node.
`jsonwebtoken`^9.0.2
Sign and verify JWTs.
`date-fns`^2.30.0
Modular date utilities, lighter alternative to moment.
`crypto-js`^4.2.0
Hashes, HMAC, and symmetric ciphers.
## Runtime 2023.04
The 2023.04 runtime runs on Node 16 with Playwright 1.33 and is kept around for existing checks. New checks default to 2026.05 and there's no automatic migration, switch the runtime on the monitor's settings page when you're ready.
Node
16.x
Playwright
`playwright ^1.33.0`, `@playwright/test 1.33`
TypeScript
`typescript ^5.0.4`
Same package set
Lodash, moment, axios, date-fns, crypto-js, jsonwebtoken, uuid, btoa, expect, on the older versions that shipped at the time.
Web Vitals
Not collected on this runtime. Switch to 2026.05 to enable them.
## Environment variables
Secrets, tokens, and per-monitor configuration belong in environment variables, not in the script. Add them in the monitor's settings panel below the editor and reference them from the script as `process.env.NAME`.
## Double check
Double check is enabled by default. When a run fails, the runtime immediately retries from a different region before opening an outage. This filters out network blips and one-shot flake without making you wait for the next scheduled run.
## Timeouts
Each browser check has a 2-minute global timeout for the entire run. Individual tests inherit Playwright's 30-second default. Override the per-test timeout when you have a slow flow:
test.setTimeoutJS
```
test.setTimeout(120_000); // 2 minutes in milliseconds
```
Long flows are usually better split into separate checks, one per critical path, rather than packed into a single 2-minute run.
## Run logs and storage
Every run keeps its logs, screenshots, video, and trace indefinitely. Failed runs in 2026.05 attach a video of the run and a Playwright trace to the log row, so you can replay exactly what the browser did.
## Example script
A login flow with two assertions, using `process.env` for credentials:
login.spec.tsTS
```
import { test, expect } from '@playwright/test';
test.beforeEach(async ({ page }) => {
await page.goto('https://app.acme.com/login');
await page.locator('input[type="text"]').type(process.env.EMAIL);
await page.locator('input[type="password"]').type(process.env.PASSWORD);
await page.getByRole('button', { name: 'Sign in', exact: true }).click();
});
test('has title', async ({ page }) => {
await expect(page).toHaveTitle(/Acme/);
});
test('is logged in', async ({ page }) => {
const content = page.locator('#project-id');
await expect(content).toHaveText('project_12345');
});
```
## Troubleshooting
**The check fails with 'Test timeout of 30000ms exceeded'**
One step in the test never completed, usually a locator that matches nothing or a page that never finished loading. Open the trace on the failed run to see where time was spent. If the flow is legitimately slow, raise the limit with `test.setTimeout`, and keep the whole run under the 2-minute cap.
**A locator that works locally fails in the check**
The page often renders differently in headless Chromium: cookie banners, geo popups, and A/B variants show up for a fresh session in a datacenter region. Watch the video of the failed run to see what the browser saw, then dismiss the overlay in the script or use a locator that doesn't depend on it. Prefer `getByRole` over CSS selectors so a class rename doesn't break the check.
**The check is flaky, alternating pass and fail**
Most flake comes from racing the app: asserting before data loads, or a hard `waitForTimeout` that is sometimes too short. Replace sleeps with web-first assertions like `await expect(locator).toBeVisible()`, which retry until the condition is met. Double check already retries failures from a second region before opening an outage, so a persistent alternation points at the script or the app, not the network.
**Login works in the browser but not in the script**
Check that the credentials are set as environment variables on the monitor and read with `process.env`, they are not copied from your local `.env`. Bot protection and captchas also trigger more often for datacenter IPs, so whitelist the probe regions or use a dedicated test account on a captcha-free path.
**The run passes but takes most of the 2-minute budget**
Split the flow into separate checks, one per critical path. Shorter checks give clearer alerts, and a slow step in one flow won't push another into the global timeout.
## Next steps
[
Playwright templates→
Twelve ready-to-paste scripts for login, signup, search, checkout, performance budgets, and more.
](https://hyperping.com/docs/monitoring/browser-check-templates)[
Run Playwright locally→
Mirror the runtime on your machine so scripts behave the same locally and in production.
](https://hyperping.com/docs/monitoring/local-playwright-setup)[
Datacenter regions→
Pick which probe regions run each check to cover the geographies your users are in.
](https://hyperping.com/docs/monitoring/datacenter-regions)[
Monitor logs→
Inspect the details of every check Hyperping performs on your monitors.
](https://hyperping.com/docs/monitoring/logs)
New to Playwright? The [Learn Playwright guides](https://hyperping.com/learn/playwright) cover locators, assertions, waits, and codegen from scratch. For the full API, see the upstream [Playwright docs](https://playwright.dev/docs/writing-tests).
[← Getting started](https://hyperping.com/docs/monitoring/getting-started)[Browser check templates →](https://hyperping.com/docs/monitoring/browser-check-templates)
[](https://x.com/hyperping)[](https://www.linkedin.com/company/hyperping)
© 2026 Hyperping
---
Source: https://hyperping.com/docs/monitoring/bulk-edit-monitors
# Edit monitors in bulk
Select several monitors from the list and change their check interval, locations, escalation policy, status or group in one save. You can also mute alerts on the whole selection while you deploy.
Bulk edit is useful when a change applies to more than one monitor at a time:
- You created a new escalation policy and want every production monitor to use it.
- You upgraded your plan and want a group of monitors checked every 30 seconds instead of every 5 minutes.
- You are about to deploy and want to silence alerts on the affected services for the next hour.
- You added a datacenter region and want your customer-facing monitors checked from there too.
The bulk edit toolbar appears at the bottom of the Monitors page once at least one monitor is selected
> **Before you start**
>
> You need the Owner, Admin or Member role in the project. Viewers can browse monitors but cannot edit them. See [Roles and permissions](https://hyperping.com/docs/projects/roles-permissions).
## Select monitors
1. Open the Monitors page
In the sidebar, click **Monitors**. Use the search field or **Filter** first if you want to narrow the list to a group, a protocol or a status.
2. Tick the monitors you want to change
Hover a row and the status dot turns into a checkbox. Click it to add the monitor to the selection. Click it again to remove it.
3. Select a range with Shift
Hold **Shift** and click a checkbox to select every monitor between the last one you ticked and this one. Shift-click again on a fully selected range to deselect it.
4. Use the toolbar
A toolbar appears at the bottom of the page with the number of monitors selected. Click the **×** next to it to clear the selection.
Hover a row to reveal its checkbox. Selected monitors keep a blue checkbox.
> **Browser checks are edited separately**
>
> A selection holds either regular monitors (HTTP, ping, port, DNS) or [browser checks](https://hyperping.com/docs/monitoring/browser-checks), never both. Once you tick one type, checkboxes of the other type stop responding until you clear the selection. Browser checks have their own intervals and run from Frankfurt and San Francisco only.
## Apply a change
Each dropdown in the toolbar stages one change. Pick the values you want, then click **Save**. Anything you leave untouched keeps its current value on every monitor.
1. Pick the new values
Open a dropdown, for example **Check interval**, and choose a value. The button shows the value you picked. You can stage several changes before saving.
2. Click Save
**Save** stays disabled until at least one change is staged. Once saved, the selection is cleared and the list refreshes with the new settings.
Choosing a check interval for the selected monitors
### What you can change
| Option | What it does | Notes |
| --- | --- | --- |
| **Locations** | Replaces the datacenter regions the selected monitors check from. | Multi-select, with **Select all**. The new list replaces the old one, it is not merged. |
| **Check interval** | Sets how often each monitor runs, from every 10 seconds to once a day. | Browser checks go from every 5 minutes to every 24 hours. The lowest intervals depend on your plan. |
| **Escalation policy** | Attaches an escalation policy, or removes it with **No escalation policy**. | See [Escalation policies](https://hyperping.com/docs/monitoring/escalation-policies). |
| **Status** | Sets the monitors to **Active** or **Paused**. | Paused monitors stop checking and stop alerting. To keep checking but stop alerting, use **Mute alerts** instead. |
| **Group** | Moves the monitors into a group, or out of any group with **No group**. | Groups are the folders you see on the Monitors page. |
When every selected monitor already shares the same interval, policy or status, the button shows that value. When they differ, it shows a generic label such as **Check interval** until you pick one.
## Mute alerts on a selection
**Mute alerts** works differently from the other dropdowns: it applies as soon as you pick a duration, without clicking **Save**. A mute is a timer, and a timer that only starts on a later click is hard to reason about.
- Choose **For 15 minutes**, **For 1 hour**, **For 4 hours**, **Until tomorrow 9am** or **For 24 hours**.
- The monitors keep being checked. Uptime and response times are still recorded, only the notifications stop.
- A mute is project-wide. Nobody on the team gets paged for those monitors until the timer runs out.
- When every monitor in the selection is muted, the button reads **Muted** and offers **Unmute for everyone**. It never unmutes a monitor you did not select.
> **Muting versus pausing**
>
> Mute when you expect noise you do not need to hear about, like a deploy. Pause when you want the checks to stop entirely, for example on a decommissioned service. For a planned window with a public announcement, use a [maintenance window](https://hyperping.com/docs/maintenance/create-maintenance) instead.
## Examples
**Rolling out a new on-call rotation.** A team creates an escalation policy for its platform squad, filters the Monitors page on the _Platform_ group, selects everything with Shift-click and attaches the policy in one save.
**Deploying at lunch.** Before shipping a change to the checkout service, an engineer selects the four monitors covering it and mutes alerts for 1 hour. The checks keep running, so they can still watch the response times during the deploy.
**Tightening intervals after an upgrade.** After moving to a plan with 30-second checks, an admin selects the customer-facing monitors and switches them from every 5 minutes to every 30 seconds, leaving internal tools on their slower cadence.
## Troubleshooting
**A checkbox does not respond.** Your selection already contains the other kind of monitor. Clear it with the **×** in the toolbar, then start again with monitors of the same type.
**Save is disabled.** No change is staged yet. Pick a value in at least one dropdown. Muting alerts does not enable **Save**, because it is applied immediately.
**The locations I added replaced the existing ones.** This is expected. The **Locations** dropdown sets the full list of regions for the selected monitors. Tick every region you want, not only the new one.
**A monitor was left out of the shift-click range.** Shift-click only selects monitors of the same type as your selection. Browser checks in the range are skipped when you started with regular monitors, and the other way round.
## Next steps
[
Edit a monitor→
Change the URL, headers, assertions and alert delay of a single monitor.
](https://hyperping.com/docs/monitoring/edit-monitor)[
Escalation policies→
Route alerts in order, with delays, until resolved.
](https://hyperping.com/docs/monitoring/escalation-policies)[
Datacenter regions→
Where checks run from, and how regions rotate.
](https://hyperping.com/docs/monitoring/datacenter-regions)[
Maintenance windows→
Schedule downtime and pause alerts on a status page.
](https://hyperping.com/docs/maintenance/create-maintenance)
[← Edit a monitor](https://hyperping.com/docs/monitoring/edit-monitor)[Delete a monitor →](https://hyperping.com/docs/monitoring/delete-monitor)
[](https://x.com/hyperping)[](https://www.linkedin.com/company/hyperping)
© 2026 Hyperping
---
Source: https://hyperping.com/docs/monitoring/create-monitor
# How to create a monitor
Monitors are the building block of [Hyperping's uptime monitoring](https://hyperping.com/uptime-monitoring): every alert, report and status page starts from one. This page covers every setting. If you just want the fast path, take the [quickstart](https://hyperping.com/docs/monitoring/quickstart).
From your [dashboard](https://app.hyperping.io), click [**New monitor**](https://app.hyperping.io/monitors/new).
## Choose a name
A human readable name, like "API" or "Website". It appears in your dashboard, alert notifications and reports, and can be renamed on a status page without touching the monitor.
## Choose a protocol
The most common protocol is **HTTP**, but Hyperping monitors more than web endpoints:
- **HTTP**: monitors websites and APIs through their status code. Any response between 200 and 299 counts as up by default.
- **ICMP (ping)**: sends echo requests to check that a host is alive. See [Ping and port monitoring](https://hyperping.com/docs/monitoring/ping-port).
- **Port**: checks that a TCP port accepts connections, for databases, mail servers or any network service.
- **DNS**: queries a record (A, AAAA, CNAME, MX, TXT and more) and verifies the answer matches what you expect. See [DNS monitoring](https://hyperping.com/docs/monitoring/dns).
- **Browser check**: runs a Playwright script in a headless browser to test full user flows. See [Browser checks](https://hyperping.com/docs/monitoring/browser-checks).
## Set a host or endpoint
For HTTP, the endpoint must start with `http://` or `https://`. For ICMP and port checks, use a hostname or an IP address.
## Choose regions
Pick where checks run from. Checks rotate through your selected [regions](https://hyperping.com/docs/monitoring/datacenter-regions), one region at a time:
1. Check from Paris: OK
2. Check from Frankfurt: OK
3. Check from London: failure. Hyperping immediately double-checks from your other selected regions, and only confirmed failures open an outage and trigger alerts.
> **Regions affect response times**
>
> Response times are measured from the checking region. If your service is hosted in the US and you only check from Europe, expect higher numbers. Pick regions close to your users.
## Pick a check interval
The frequency at which your monitor is checked. The default is every 30 seconds.
> **Plan availability**
>
> Intervals below 30 seconds are available on the Business and Enterprise plans. See [pricing](https://hyperping.com/pricing).
## IP version
By default, monitors reach your target over IPv4. To check that your service answers over IPv6, open **Advanced settings** and switch **IP version** to **IPv6** in the **Network** block. An IPv6 monitor is checked over IPv6 only: if the target has no AAAA record or doesn't answer on IPv6, the check fails, even when IPv4 works.
An IPv6 monitor: regions without an IPv6 probe are greyed out
- **Protocols**: HTTP, port and ping (ICMP). DNS and browser checks don't have the setting.
- **Regions**: every region has an IPv6 probe except Bahrain. In IPv6 mode, regions without one are greyed out in the picker.
- **Shortcut**: **New monitor** → **Website / API (IPv6)** opens the form directly on IPv6.
> **Monitoring both IPv4 and IPv6**
>
> A monitor uses one IP version, never both. To cover a dual-stack service, create two monitors on the same URL, one per version: each one alerts on its own, so you know which path broke.
Through the API, set `ip_version` to `6`. See the [Create monitor API](https://hyperping.com/docs/api/monitors/create).
## HTTP advanced settings
### Redirects
Choose whether your monitor should follow HTTP redirects or treat them as final responses.
### Expected status code
By default, any status code between 200 and 299 counts as up. If your endpoint is supposed to answer differently, an auth-protected route returning 401 or a forbidden route returning 403, select that expected status code instead: the monitor is then up only when it answers exactly as intended.
### Text body assertion
Set a text that the response body must include. This catches error pages served with a 200 and empty renders. See [Keyword monitoring](https://hyperping.com/docs/monitoring/keyword-monitoring) for patterns and use cases.
### Custom HTTP parameters
Customize the request headers and body, for authenticated endpoints or POST requests.
## Create via API or Terraform
Everything above is scriptable:
```bash
curl -X POST https://api.hyperping.io/v1/monitors \
-H "Authorization: Bearer ${API_TOKEN}" \
-H "Content-Type: application/json" \
-d '{
"name": "Website",
"url": "https://acme.com",
"protocol": "http",
"check_frequency": 30,
"regions": ["paris", "frankfurt", "amsterdam", "london"],
"request_headers": [
{ "name": "X-Request-Header", "value": "Header value" }
]
}'
```
**Response201 Created**
```json
{
"name": "Website",
"url": "https://acme.com",
"paused": false,
"regions": ["paris", "frankfurt", "amsterdam", "london"],
"http_method": "GET",
"check_frequency": 30,
"uuid": "mon_3GhAQMYGEQuyUH",
"status": "up",
"ssl_expiration": 90,
"alerts_wait": 0
}
```
Full field reference in the [Create monitor API](https://hyperping.com/docs/api/monitors/create).
## Finalize and save
Click **Save**. The first check runs immediately, metrics start computing, and you land on the monitor's detailed view with its graphs and logs.
## Troubleshooting
**The monitor shows down, but the service works in my browser**
Open the monitor's [logs](https://hyperping.com/docs/monitoring/logs) to see the response we actually received. Common causes: a status code outside your expected range, redirects not followed, or a text body assertion that no longer matches the page.
**Response times look higher than expected**
Response times are measured from the checking regions. Check them against the regions you selected; a US-hosted service checked only from Asia and Europe will read slower. See [Response times](https://hyperping.com/docs/monitoring/response-times).
**No alerts fired during an outage**
Verify the monitor's [escalation policy](https://hyperping.com/docs/monitoring/escalation-policies) assignment and test your [notification channels](https://hyperping.com/docs/projects/notification-channels) with a monitor pointing at a 404 page.
## Next steps
[
Datacenter regions→
The 18 regions your checks can run from.
](https://hyperping.com/docs/monitoring/datacenter-regions)[
Escalation policies→
Decide who gets paged, in what order, until resolved.
](https://hyperping.com/docs/monitoring/escalation-policies)[
Keyword monitoring→
Catch error pages that still return a 200.
](https://hyperping.com/docs/monitoring/keyword-monitoring)[
Grouped alerts→
One alert instead of ten during a widespread outage.
](https://hyperping.com/docs/monitoring/grouped-alerts)
[← Getting started](https://hyperping.com/docs/monitoring/getting-started)[Datacenter regions →](https://hyperping.com/docs/monitoring/datacenter-regions)
[](https://x.com/hyperping)[](https://www.linkedin.com/company/hyperping)
© 2026 Hyperping
---
Source: https://hyperping.com/docs/monitoring/datacenter-regions
# Datacenter regions
Check your services from 18 regions across 7 global zones, so you catch outages wherever your users are.
Hyperping performs HTTP, port and ICMP pings from multiple regions, one region at a time per minute.
Selecting regions for a monitor
> **What happens when a region fails a check?**
>
> Checks rotate through your selected regions one region at a time. A failure is immediately double-checked from your other selected regions, and only confirmed failures open an outage and trigger alerts. See [Create a monitor](https://hyperping.com/docs/monitoring/create-monitor).
> **IPv6**
>
> Every region can check over IPv6 except Bahrain. Monitors use IPv4 by default; switch a monitor to IPv6 in its advanced settings. See [IP version](https://hyperping.com/docs/monitoring/create-monitor#ip-version).
There are currently 18 available regions across 7 global zones:
## North America
- **🇺🇸 San Francisco**, United States
- **🇺🇸 N. Virginia**, United States
- **🇺🇸 N. California**, United States
- **🇺🇸 New York City**, United States
- **🇨🇦 Toronto**, Canada
## South America
- **🇧🇷 São Paulo**, Brazil
## Europe
- **🇬🇧 London**, United Kingdom
- **🇫🇷 Paris**, France
- **🇩🇪 Frankfurt**, Germany
- **🇳🇱 Amsterdam**, Netherlands
## Asia
- **🇰🇷 Seoul**, South Korea
- **🇮🇳 Mumbai**, India
- **🇮🇳 Bangalore**, India
- **🇸🇬 Singapore**, Singapore
- **🇯🇵 Tokyo**, Japan
## Australia
- **🇦🇺 Sydney**, Australia
## Middle East
- **🇧🇭 Bahrain**, Bahrain
## Africa
- **🇿🇦 Cape Town**, South Africa
To ensure the highest uptime among all pingers with redundancy, we use a mix of different leading hosting providers.
## Next steps
[
All monitor settings→
Pick regions, intervals and protocols for each monitor.
](https://hyperping.com/docs/monitoring/create-monitor)[
Response times→
Track latency as measured from each checking region.
](https://hyperping.com/docs/monitoring/response-times)[
Ping and port monitoring→
Monitor hosts and services that don't speak HTTP.
](https://hyperping.com/docs/monitoring/ping-port)[
DNS monitoring→
Catch expired domains and hijacked records before your users do.
](https://hyperping.com/docs/monitoring/dns)
[← Create a monitor](https://hyperping.com/docs/monitoring/create-monitor)[False positives →](https://hyperping.com/docs/monitoring/false-positives)
[](https://x.com/hyperping)[](https://www.linkedin.com/company/hyperping)
© 2026 Hyperping
---
Source: https://hyperping.com/docs/monitoring/delete-monitor
# Delete a monitor
Remove a monitor you no longer need, and know exactly what you lose when you do.
> **Deleting cannot be undone**
>
> Deleting permanently removes the monitor and all of its historical data: response times, outage records, and logs. Only need to stop checks temporarily? [Pause the monitor instead](#pause-vs-delete).
You might want to delete a monitor when:
- The service or endpoint being monitored has been decommissioned
- You created a duplicate monitor by mistake
- You are cleaning up monitors that are no longer relevant
## How to delete a monitor
1. Open the monitor
Open the [Hyperping dashboard](https://app.hyperping.io) and click on the monitor you want to delete.
2. Go to the Danger zone tab
It sits on the monitor's detail page.
3. Click the delete button
Checks and notifications stop immediately.
The delete option is in the Danger zone tab of the monitor's detail page
## What gets deleted
| Data | Result |
| --- | --- |
| Monitor configuration | Permanently removed |
| Response time history | Permanently removed |
| Outage records | Permanently removed |
| Check logs | Permanently removed |
| Notifications | Stopped immediately, no further alerts sent |
| Status page services | Removed from any status page that used this monitor |
## Pause vs. delete
If you are unsure whether you will need the monitor again, pause it instead. Pausing stops all checks and notifications but keeps the monitor's configuration and history intact. You can resume a paused monitor at any time.
Delete only when you are certain the monitor is no longer needed.
Pausing is also scriptable: set the `paused` field with the [Update monitor API](https://hyperping.com/docs/api/monitors/update).
```bash
curl -X PUT https://api.hyperping.io/v1/monitors/mon_3GhAQMYGEQuyUH \
-H "Authorization: Bearer ${API_TOKEN}" \
-H "Content-Type: application/json" \
-d '{ "paused": true }'
```
## Delete via the API
Send a `DELETE` request with the monitor's UUID. The same warning applies: all monitoring data and historical metrics are permanently deleted.
```bash
curl -X DELETE https://api.hyperping.io/v1/monitors/mon_3GhAQMYGEQuyUH \
-H "Authorization: Bearer ${API_TOKEN}"
```
**Response204 No Content**
```json
(empty response body)
```
Full reference in the [Delete monitor API](https://hyperping.com/docs/api/monitors/delete).
## Troubleshooting
**I accidentally deleted a monitor**
Deleted monitors cannot be recovered. You will need to [create a new monitor](https://hyperping.com/docs/monitoring/create-monitor) with the same settings. Historical data from the deleted monitor is not recoverable.
**The delete option is not available**
Make sure you are on the monitor's **Danger zone** tab, not the overview or notifications tab. Both Owners and Teammates with project access can delete monitors.
## Next steps
[
Create a monitor→
Protocols, regions, check intervals, advanced HTTP options.
](https://hyperping.com/docs/monitoring/create-monitor)[
Edit a monitor→
Change settings or alert timing without recreating anything.
](https://hyperping.com/docs/monitoring/edit-monitor)[
Monitors API→
List, create, update, and delete monitors programmatically.
](https://hyperping.com/docs/api/monitors)
[← Edit a monitor](https://hyperping.com/docs/monitoring/edit-monitor)[Escalation policies →](https://hyperping.com/docs/monitoring/escalation-policies)
[](https://x.com/hyperping)[](https://www.linkedin.com/company/hyperping)
© 2026 Hyperping
---
Source: https://hyperping.com/docs/monitoring/dns
# DNS Monitoring
Get alerted when a DNS record stops resolving or resolves to the wrong value, before your users notice.
DNS problems are easy to miss: your servers stay up, your HTTP checks may keep passing from cached resolvers, yet part of your audience can no longer reach you. A DNS monitor queries your records on a schedule and treats a wrong or missing answer as downtime, so it goes through the same alerting pipeline as any other monitor.
## What DNS monitoring catches
- **Expired domains**: When a domain registration lapses, its records stop resolving. A DNS monitor fails immediately instead of waiting for someone to report that your site is unreachable. To be warned before that happens, turn on [domain expiry alerts](https://hyperping.com/docs/monitoring/domain-expiry).
- **Hijacked or misconfigured records**: The record still resolves, but to a value you didn't set. Pair the monitor with an expected answer so any unexpected change triggers an alert.
- **Propagation failures**: After a DNS change, some resolvers keep serving stale answers. Point monitors at specific nameservers to confirm the new value is live where it matters.
> **Plan availability**
>
> DNS monitoring is included in the Essentials, Pro and Business plans. See the [pricing page](https://hyperping.com/pricing) for details.
## Create a DNS monitor
1. Open the new monitor form
From your [dashboard](https://app.hyperping.io), click the **New monitor** card.
2. Choose the DNS protocol
Select **DNS** in the protocol list.
3. Enter the hostname
For example `example.com`. Unlike HTTP monitors, you enter a bare hostname rather than a full URL.
4. Pick the record type
Optionally set an expected answer and a nameserver, both covered below.
5. Save the monitor
Checks start right away at your chosen frequency.
DNS monitors share the rest of their configuration with other monitor types: check frequency, [regions](https://hyperping.com/docs/monitoring/datacenter-regions), and alert settings all work the same way. See [Create a monitor](https://hyperping.com/docs/monitoring/create-monitor) for the general workflow.
A DNS monitor: hostname, record type, expected answer, and optional nameserver
## Choose a record type
Each DNS monitor checks one record type on the hostname. The default is `A`. Supported types:
- **A**: IPv4 address of the hostname.
- **AAAA**: IPv6 address of the hostname.
- **CNAME**: Alias pointing to another hostname.
- **MX**: Mail servers for the domain. Useful to catch email delivery breakage early.
- **NS**: Authoritative nameservers for the domain.
- **TXT**: Text records, such as SPF, DKIM, or domain verification entries.
- **SOA**: Start of authority record for the zone.
- **SRV**: Service locator records.
- **CAA**: Certificate authority authorization, controlling who can issue certificates for the domain.
- **PTR**: Reverse DNS lookup.
To watch several record types on the same domain, create one monitor per record type.
## Validate answers with an expected value
By default, a DNS monitor is up as long as the query returns an answer. To also verify _what_ it returns, set an expected answer. The monitor fails when no record contains the expected string.
For example, an `A` record monitor with the expected answer `192.0.2.1` stays up while the hostname resolves to that address, and goes down if the record is deleted or changed to point somewhere else. This is how you detect hijacked or accidentally edited records rather than just missing ones.
The match is a substring check that ignores case, and one matching record is enough, so for records with multiple values (like `MX` or `TXT`) you can validate that one specific entry is present. `MX` and `SRV` records are compared on their host (not the priority), `SOA` on its primary nameserver and `CAA` on its value.
## Query a specific nameserver
By default, each monitoring region queries through its own resolver, which reflects what a typical visitor experiences. You can instead point a monitor at a specific nameserver, by IP address or hostname, for example `8.8.8.8` or `ns1.example.net`.
Querying a specific nameserver is useful when you want to:
- Check your authoritative nameservers directly, bypassing resolver caches, so you see record changes the moment they're published.
- Verify propagation on a public resolver after a DNS change.
- Compare answers across resolvers by creating one monitor per nameserver with the same expected answer.
> **Also worried about certificates and registrations?**
>
> SSL monitoring is enabled by default on every HTTPS monitor, with expiry reminders at the threshold you choose. Domain expiry alerts warn you before the registration itself lapses. See [SSL monitoring](https://hyperping.com/docs/monitoring/ssl) and [domain expiry monitoring](https://hyperping.com/docs/monitoring/domain-expiry).
## Alerting and escalation
DNS monitors plug into the same alerting as HTTP monitors. When a check fails, you're notified on your configured channels, and you can attach an [escalation policy](https://hyperping.com/docs/monitoring/escalation-policies) so DNS incidents escalate through your team like any other outage. Alert delay settings apply too, so you can wait a few minutes before alerting or route failures straight to your on-call.
## Create DNS monitors via the API
DNS monitors can be managed programmatically. With the [monitors API](https://hyperping.com/docs/api/monitors/create), set `protocol` to `dns` and use the `dns_record_type`, `dns_expected_answer`, and `dns_nameserver` fields:
```bash
curl -X POST https://api.hyperping.io/v1/monitors \
-H "Authorization: Bearer ${API_TOKEN}" \
-H "Content-Type: application/json" \
-d '{
"name": "Website DNS",
"url": "example.com",
"protocol": "dns",
"dns_record_type": "A",
"dns_expected_answer": "192.0.2.1",
"dns_nameserver": "8.8.8.8"
}'
```
The same fields are available when [updating a monitor](https://hyperping.com/docs/api/monitors/update), and through the [MCP server](https://hyperping.com/docs/mcp). The [Terraform provider](https://hyperping.com/docs/community/terraform) doesn't manage DNS monitors yet.
## Next steps
[
SSL monitoring→
Certificate checks and expiry reminders on every HTTPS monitor.
](https://hyperping.com/docs/monitoring/ssl)[
Ping and port monitoring→
Monitor hosts and services that don't speak HTTP.
](https://hyperping.com/docs/monitoring/ping-port)[
Escalation policies→
Route alerts in order, with delays, until resolved.
](https://hyperping.com/docs/monitoring/escalation-policies)[
Create monitor API→
Every monitor field, scriptable from your own tooling.
](https://hyperping.com/docs/api/monitors/create)
[← Domain expiry monitoring](https://hyperping.com/docs/monitoring/domain-expiry)[Browser checks →](https://hyperping.com/docs/monitoring/browser-checks)
[](https://x.com/hyperping)[](https://www.linkedin.com/company/hyperping)
© 2026 Hyperping
---
Source: https://hyperping.com/docs/monitoring/domain-expiry
# Domain Expiry Monitoring
Get warned before a domain registration lapses. When a domain expires, its website, email and certificates stop working at once, and an expired domain can be bought by someone else. Hyperping reads the expiry date from the registry and reminds you ahead of time, like it does for [SSL certificates](https://hyperping.com/docs/monitoring/ssl).
## How it works
- **Which domain.** The registered domain behind the monitor's host: `api.status.example.co.uk` is checked as `example.co.uk`. It works for HTTP, ping, port and DNS monitors.
- **Where the date comes from.** The registry itself, over RDAP, the successor of WHOIS. For the extensions without RDAP whose WHOIS still publishes an expiry date (`.io`, `.co`, `.me` and others), WHOIS is used instead.
- **How often.** Once a day for domains expiring within 45 days, once a week otherwise. Many monitors on the same domain share one lookup.
- **Shown on the monitor.** The certificate details on the monitor's overview include the domain, its expiry date and the registrar.
> **Extensions without published dates**
>
> Some registries don't publish expiry dates at all, for example `.de`, `.eu`, `.ch`, `.be` and `.nl`. Domains under them show "not published by this registry" and don't get reminders. Subdomains of hosting platforms (`*.github.io`, `*.vercel.app`) aren't registrations you own, so they're skipped too.
## Alerts
In the monitor's **Notifications** tab, **Domain expiry alerts** sets when the first reminder goes out: 7, 14, 30, 60 or 90 days before the registration ends, or never. Reminders then follow at each step below it: 60, 30, 15, 7, 3 and 1 days.
- **New monitors** created from the dashboard start at 14 days. Monitors created with the API or the MCP server stay off unless you send `domain_alert_days`, and monitors created before the feature launched stay off until you pick a threshold.
- **One reminder per domain.** Ten monitors on the same domain in a project send one reminder, not ten. The earliest threshold among them wins.
- **Who gets them.** Everyone on the project by email, plus the SSL notification channels of those monitors. PagerDuty and Opsgenie are only paged in the last 24 hours.
- **Renewals.** Registrars often renew in the last days, so the registry is asked again right before a reminder goes out: a domain renewed meanwhile gets no reminder. If you had already been warned, a **renewed** notice goes to the SSL notification channels (not by email), and any PagerDuty or Opsgenie page is resolved.
## API and Terraform
On [monitors in the API](https://hyperping.com/docs/api/monitors/update), `domain_alert_days` sets the threshold (-1 for never) and the read-only `domain_expiration` gives the whole days left before the registration expires, or `null` when the registry doesn't publish it. The Terraform provider's `hyperping_monitor` resource takes `domain_alert_days` too.
```bash
curl -X PUT https://api.hyperping.io/v1/monitors/mon_3GhAQMYGEQuyUH \
-H "Authorization: Bearer ${API_TOKEN}" \
-H "Content-Type: application/json" \
-d '{ "domain_alert_days": 30 }'
```
Webhooks added as SSL channels receive `domain_expiring` and `domain_renewed` events. See [webhook payloads](https://hyperping.com/docs/monitoring/ssl).
## Troubleshooting
**My domain is on auto-renew but I still got a reminder**
Auto-renewal usually happens close to the end date, and the registry only shows the new date once the registrar has paid it. The reminder means the renewal hasn't reached the registry yet. Check that auto-renew is on and the payment method on file is valid.
**The expiry date is missing**
Either the registry doesn't publish it (see the extensions above), or the first lookup hasn't run yet. Lookups run when you turn alerts on, then daily.
## Next steps
[
SSL monitoring→
Certificate checks and expiry reminders on every HTTPS monitor.
](https://hyperping.com/docs/monitoring/ssl)[
DNS monitoring→
Catch hijacked or broken records before your users do.
](https://hyperping.com/docs/monitoring/dns)
[← SSL monitoring](https://hyperping.com/docs/monitoring/ssl)[DNS monitoring →](https://hyperping.com/docs/monitoring/dns)
[](https://x.com/hyperping)[](https://www.linkedin.com/company/hyperping)
© 2026 Hyperping
---
Source: https://hyperping.com/docs/monitoring/edit-monitor
# How to edit a monitor
Change a monitor's name, URL, request headers, or any other check setting without recreating it. Everything lives in the monitor's **Settings** tab.
> **Before you start**
>
> You need an existing monitor. [Create a monitor](https://hyperping.com/docs/monitoring/create-monitor) walks through every setting and what it does. To change the interval, regions, escalation policy or group of several monitors at once, see [Edit monitors in bulk](https://hyperping.com/docs/monitoring/bulk-edit-monitors).
## Open the monitor settings
1. Open the monitor
From your dashboard, click the monitor you want to edit.
2. Go to the Settings tab
Adjust the name, URL, check interval, regions, [IP version](https://hyperping.com/docs/monitoring/create-monitor#ip-version), and HTTP options, then save.
Edit monitor interface in the Settings tab
See [Create a monitor](https://hyperping.com/docs/monitoring/create-monitor) for what each parameter does.
## Change when alerts trigger
By default, you are alerted as soon as a downtime is confirmed. If you prefer to ignore short blips, add a delay: open the monitor's **Notifications** tab and set how long the check must stay down before you are notified.
Notification delay setting in the Notifications tab
For example, with a 5 minute delay, a downtime that recovers after 2 minutes will not trigger any alert.
> **Need alerts to escalate through your team?**
>
> Link an [escalation policy](https://hyperping.com/docs/monitoring/escalation-policies) to the monitor to route alerts in order, with delays, until the outage resolves.
## Edit via the API
Every setting is scriptable with a `PUT` on the monitor. The alert delay is the `alerts_wait` field, in minutes, and `-1` disables alerts entirely.
```bash
curl -X PUT https://api.hyperping.io/v1/monitors/mon_3GhAQMYGEQuyUH \
-H "Authorization: Bearer ${API_TOKEN}" \
-H "Content-Type: application/json" \
-d '{
"name": "Website",
"url": "https://acme.com",
"regions": ["paris", "frankfurt", "amsterdam", "london"],
"http_method": "GET",
"check_frequency": 30,
"request_headers": [
{ "name": "X-Request-Header", "value": "Header value" }
],
"protocol": "http"
}'
```
**Response200 OK**
```json
{
"name": "Website",
"url": "https://acme.com",
"paused": false,
"regions": ["paris", "frankfurt", "amsterdam", "london"],
"http_method": "GET",
"check_frequency": 30,
"protocol": "http",
"follow_redirects": true,
"ip_version": 4,
"expected_status_code": "2xx",
"uuid": "mon_3GhAQMYGEQuyUH",
"status": "up",
"ssl_expiration": 90,
"alerts_wait": 0
}
```
Full field reference in the [Update monitor API](https://hyperping.com/docs/api/monitors/update).
## Next steps
[
Delete a monitor→
Pause vs delete, and what happens to your data.
](https://hyperping.com/docs/monitoring/delete-monitor)[
Monitor logs→
Inspect every check: status code, response time, region.
](https://hyperping.com/docs/monitoring/logs)[
Escalation policies→
Route alerts in order, with delays, until resolved.
](https://hyperping.com/docs/monitoring/escalation-policies)[
Datacenter regions→
Where checks run from, and how regions rotate.
](https://hyperping.com/docs/monitoring/datacenter-regions)
[← Create a monitor](https://hyperping.com/docs/monitoring/create-monitor)[Delete a monitor →](https://hyperping.com/docs/monitoring/delete-monitor)
[](https://x.com/hyperping)[](https://www.linkedin.com/company/hyperping)
© 2026 Hyperping
---
Source: https://hyperping.com/docs/monitoring/escalation-policies
# Escalation policies
Route alerts through the right channels in the right order when an incident occurs. Instead of paging every channel at once, define a sequence of steps with delays: each step fires after its delay, until the outage resolves. Acknowledging an outage stops its repeat alerts, not the escalation, so a second responder still hears about an outage that lasts.
> **Before you start**
>
> Connect the channels you plan to page in your [notification channels](https://hyperping.com/docs/projects/notification-channels), and make sure teammates have their email and phone number set in their [account settings](https://app.hyperping.io/settings/general) so they can receive email, SMS, and phone call alerts.
Escalation policies are useful when:
- You want Slack notifications first, then SMS or phone calls if no one responds
- Different people need to be contacted at different stages of an incident
- You have on-call rotations and want alerts sent to whoever is currently on duty
- You need to reduce alert noise while still making sure critical issues get attention
Your escalation policies, with the channels and monitors each one covers.
## Create an escalation policy
1. Open Escalation Policies
Go to [Escalation Policies](https://app.hyperping.io/escalation-policies) in the sidebar and click **New escalation policy**.
2. Name the policy
Give it a descriptive name, for example "Production Critical" or "Business Hours".
3. Configure your first escalation step
Set the delay and pick the notification channels for the first step. The settings are detailed in the next section.
4. Save
Click **Save** at the top-right when you are done.
## Configure escalation steps
Each escalation policy consists of one or more steps. A step defines which channels receive alerts and how long Hyperping waits before moving to the next step.
### Set the delay
Set the delay in minutes for when the step triggers. A delay of 0 means the step fires instantly when the incident starts. For the second step onward, the delay is counted from the previous step.
### Add notification channels
You can add multiple channels to a single step. When the step triggers, all channels in that step receive the alert at the same time. Available channels include email, SMS, phone call, Slack, Microsoft Teams, and any other [configured integrations](https://hyperping.com/docs/projects/notification-channels).
For email, SMS, or phone call notifications, you can select individual recipients or use the "Everyone" option to notify all teammates in the project.
### Add more steps
Click **\+ Add another escalation step** at the bottom of the policy. Each additional step acts as a fallback if the incident is not yet resolved after the previous step's delay.
A two-step policy: page one channel immediately, then more channels three minutes later.
## Use on-call schedules
For email, SMS, or phone call notifications, you can select an on-call schedule instead of a specific recipient. This sends alerts only to the team member who is actively on-call at the time of the incident.
On-call schedules appear in the recipient dropdown under the **On-Call Schedules** section when configuring these notification types. For more details, see the [On-call documentation](https://hyperping.com/docs/monitoring/on-call).
## Assign a policy to a monitor
1. Open the monitor
Go to a monitor's detail page.
2. Go to the Notifications tab
Alert settings for that monitor live here.
3. Select the policy
Pick an escalation policy from the **Escalation Policy** dropdown.
> **Policies replace the default behavior**
>
> Without an escalation policy, a monitor sends alerts to all configured channels simultaneously. Assigning a policy overrides this behavior and follows the step-by-step sequence instead.
## Example setup
1. Step 1, at 0 minutes
Send a Slack message to the #incidents channel.
2. Step 2, after 5 minutes
Send an SMS to the on-call engineer.
3. Step 3, after 15 minutes
Call the engineering lead and send an email to the team.
This setup gives the team five minutes to respond in Slack before the alert escalates to SMS, and another ten minutes before triggering phone calls.
> **Want a single alert during a widespread outage?**
>
> When several monitors fail at once, [grouped alerts](https://hyperping.com/docs/monitoring/grouped-alerts) collapse them into one notification instead of paging your team for each monitor.
## Troubleshooting
**Alerts are skipping escalation steps**
Check that the delay between steps is long enough. If the incident is resolved before the next step triggers, remaining steps are cancelled.
**A teammate is not receiving alerts**
Verify they are added as a recipient in the correct escalation step, or that they are part of the assigned on-call schedule. Also check that their notification channel (email, phone number) is configured in their [account settings](https://app.hyperping.io/settings/general).
**All channels still fire at once**
Make sure the escalation policy is assigned to the monitor. Go to the monitor's **Notifications** tab and confirm a policy is selected.
## Next steps
[
On-call schedules→
Rotations across timezones, so policies page whoever is on duty.
](https://hyperping.com/docs/monitoring/on-call)[
Grouped alerts→
One alert when multiple monitors fail within a time window.
](https://hyperping.com/docs/monitoring/grouped-alerts)[
Notification channels→
Slack, Teams, SMS, phone calls, webhooks and more.
](https://hyperping.com/docs/projects/notification-channels)[
Edit a monitor→
Alert delays and per-monitor notification settings.
](https://hyperping.com/docs/monitoring/edit-monitor)
[← Delete a monitor](https://hyperping.com/docs/monitoring/delete-monitor)[On-call →](https://hyperping.com/docs/monitoring/on-call)
[](https://x.com/hyperping)[](https://www.linkedin.com/company/hyperping)
© 2026 Hyperping
---
Source: https://hyperping.com/docs/monitoring/false-positives
# False positives
A false positive is an alert for an outage that never happened: your service was up, but the check said otherwise. Hyperping confirms every failure from multiple regions before it opens an outage, and this page covers the rest of what you can tune.
Most fake alerts come from one of three places:
- A network blip between one probe and your server, not an outage on your side
- A monitor configured more strictly than your service actually behaves
- Something between you and the internet, like a WAF or a rate limiter, blocking the probe
## How a failure gets confirmed
Checks rotate through your selected [regions](https://hyperping.com/docs/monitoring/datacenter-regions), one region at a time. When one of them fails, the failure is not trusted on its own:
```text
check from London
|
v
FAILURE
|
v
+-----------------------+
| instant double check |
| from your other |
| regions |
+-----------------------+
|
+-------+-------+
| |
all fail any succeeds
| |
v v
outage opens no outage
alerts sent no alert
kept in the logs
```
1. One region reports a failure
Bad status code, a broken assertion, an unreachable host, or a timeout. Nothing is sent to your team yet.
2. Every other selected region re-checks immediately
The double check runs at once, not on the next interval, so a confirmed outage still reaches you in seconds.
3. Only a confirmed failure opens an outage
If the other regions answer normally, no outage opens and no alert goes out. The failed check stays visible in the monitor's [logs](https://hyperping.com/docs/monitoring/logs).
The probes also run on a mix of hosting providers (AWS, Scaleway, DigitalOcean) across 18 regions, so a routing problem at one provider cannot fail every check at once.
> **Select at least three regions**
>
> A monitor with a single region has nothing to double-check against. Three or four regions close to your users give the confirmation step enough independent paths to your service.
## Settings that cut the remaining noise
| Setting | What it prevents |
| --- | --- |
| Alert delay (`alerts_wait`) | Alerts on blips that resolve on their own. With a 5 minute delay, a 2 minute outage never pages anyone. |
| Expected status code | Down alerts on endpoints that legitimately answer 401, 403 or 404. |
| Follow redirects | Down alerts on a 301 or 302 that is the intended response. |
| Regions | Single-path failures. More regions mean more independent confirmations. |
| Maintenance windows | Alerts during a planned deploy or migration. |
| [Grouped alerts](https://hyperping.com/docs/monitoring/grouped-alerts) | Ten notifications for one widespread incident. |
The alert delay lives in the monitor's **Notifications** tab, or in the `alerts_wait` field of the [update monitor API](https://hyperping.com/docs/api/monitors/update), in minutes. Everything else is in [the monitor settings](https://hyperping.com/docs/monitoring/edit-monitor).
> **A delay is not free**
>
> Every minute you add to the alert delay is a minute of real downtime your team does not know about. Start at 0, and only add a delay for monitors that have proven noisy.
## When an alert still looks wrong
Open the monitor's [logs](https://hyperping.com/docs/monitoring/logs) first. They show the status code, the response time and the region for every check, which usually points straight at the cause.
**The service works in my browser but the check fails**
Your browser is not the probe. Look for a status code outside your expected range, a redirect that is not followed, or a text assertion that no longer matches the page. Logs show what Hyperping actually received.
**Checks get 403 or 429 responses**
A WAF, a bot filter or a rate limiter is blocking the probes. Datacenter IPs trigger these rules more often than residential traffic. Allow the probe regions in your firewall, or raise the rate limit for them, and lengthen the check interval if the endpoint is expensive.
**A keyword assertion fails after a copy change**
Text assertions break when the page text changes. Assert on something stable, like an element that only renders on a healthy page, rather than marketing copy. See [keyword monitoring](https://hyperping.com/docs/monitoring/keyword-monitoring).
**The alert fires every time we deploy**
Schedule a [maintenance window](https://hyperping.com/docs/maintenance) for planned work, or pause the monitor for the duration of the migration. For rolling deploys that drop a few requests, an alert delay of 2 to 3 minutes is usually enough.
**A browser check fails but the flow works manually**
Browser checks fail on any broken assertion or on the 2-minute run timeout. Open the run's screenshot, video and Playwright trace to see where the script stopped. Failed runs are already retried from a different region before an outage opens. See [browser checks](https://hyperping.com/docs/monitoring/browser-checks).
**Only one region ever fails**
That is a regional problem, not a false positive, and it is worth investigating: a CDN edge, a DNS record or a peering route can be broken for part of the world while the rest is fine. Compare response times per region in the logs.
## Next steps
[
Monitor logs→
Inspect every check: status code, response time, region.
](https://hyperping.com/docs/monitoring/logs)[
Datacenter regions→
The 18 regions your checks run from, and how they rotate.
](https://hyperping.com/docs/monitoring/datacenter-regions)[
Edit a monitor→
Change the alert delay, expected status code and regions.
](https://hyperping.com/docs/monitoring/edit-monitor)[
Alert triage→
What to do in the first minutes of an alert.
](https://hyperping.com/docs/playbooks/alert-triage)
[← Datacenter regions](https://hyperping.com/docs/monitoring/datacenter-regions)[Grouped Alerts →](https://hyperping.com/docs/monitoring/grouped-alerts)
[](https://x.com/hyperping)[](https://www.linkedin.com/company/hyperping)
© 2026 Hyperping
---
Source: https://hyperping.com/docs/monitoring/getting-started
# Getting started with monitoring
Everything you need to detect downtime before your customers do: one monitor, the right alert channels, and a place to watch it all. Three steps. If you are still evaluating, the [uptime monitoring overview](https://hyperping.com/uptime-monitoring) covers what Hyperping checks and how alerting works.
1. Create your first monitor
Head to your [dashboard](https://app.hyperping.io) and click the **New monitor** card. Give it a name, enter its URL, and save.
That's enough: your monitor is checked every 30 seconds from multiple regions, and its uptime and response times start filling the graphs immediately. For protocols, regions, intervals and advanced HTTP options, see [Create a monitor](https://hyperping.com/docs/monitoring/create-monitor).
2. Choose where alerts go
Down and up alerts go to your signup email by default. Add the channels your team actually watches:
- **SMS and phone calls**: set your number in your [account settings](https://app.hyperping.io/settings/general).
- **Slack, Teams, Discord**: connect a channel at the [project level](https://app.hyperping.io/project).
- **Teammates**: [invite them](https://hyperping.com/docs/projects/teammates) so they receive alerts too, with their own preferences.
- **Webhooks, PagerDuty, OpsGenie**: see all [notification channels](https://hyperping.com/docs/projects/notification-channels).
3. Watch it live
Open your monitor to see uptime, [response times](https://hyperping.com/docs/monitoring/response-times) per region, and the [logs](https://hyperping.com/docs/monitoring/logs) of every check. Your dashboard becomes the single view of everything you run.
Your monitors, at a glance
A single monitor: uptime, response time per region, certificate health, and every check.
> **You're monitoring**
>
> From here, two things make the difference on real incidents: an [escalation policy](https://hyperping.com/docs/monitoring/escalation-policies) so the right people are paged in order until the outage resolves, and a [status page](https://hyperping.com/docs/status-page/create-status-page) so your users hear it from you first.
> **Prefer to do all this in code?**
>
> Monitors can be created via the [REST API](https://hyperping.com/docs/api/monitors) or the [Terraform provider](https://hyperping.com/docs/community/terraform). The [quickstart](https://hyperping.com/docs/monitoring/quickstart) shows a complete cURL example with its response.
## Troubleshooting
**I didn't receive an alert during a real outage**
Check that the monitor is assigned the right [escalation policy](https://hyperping.com/docs/monitoring/escalation-policies), and test your [notification channels](https://hyperping.com/docs/projects/notification-channels). An easy end-to-end test: create a monitor pointing at a 404 page, which triggers the alerts.
**I'm getting alerts for blips that resolve themselves**
Select several regions on the monitor so failures are double-checked before alerting, and consider [grouped alerts](https://hyperping.com/docs/monitoring/grouped-alerts) to reduce noise during widespread issues.
## Next steps
[
All monitor settings→
Protocols, regions, check intervals, advanced HTTP options.
](https://hyperping.com/docs/monitoring/create-monitor)[
Escalation policies→
Route alerts in order, with delays, until resolved.
](https://hyperping.com/docs/monitoring/escalation-policies)[
Create a status page→
A branded status page on your own domain, live in minutes.
](https://hyperping.com/docs/status-page/create-status-page)[
Browser checks→
Test logins and checkouts with Playwright scripts.
](https://hyperping.com/docs/monitoring/browser-checks)
[← What is Hyperping?](https://hyperping.com/docs/monitoring)[Create a monitor →](https://hyperping.com/docs/monitoring/create-monitor)
[](https://x.com/hyperping)[](https://www.linkedin.com/company/hyperping)
© 2026 Hyperping
---
Source: https://hyperping.com/docs/monitoring/grouped-alerts
# Grouped alerts
Group related incidents together to reduce noise and prevent notification fatigue. When multiple monitors in the same project or escalation policy fail within a configured time window, Hyperping sends one alert instead of many.
## Configuration
You can enable grouped alerts at two levels.
### Project level
1. Open Project Settings
Go to your project settings.
2. Find the Alert grouping section
The setting applies to all monitors in the project.
3. Select a time window
Pick one from the dropdown:
- Never (disabled)
- Within 10 seconds
- Within 30 seconds
- Within 1 minute
- Within 3 minutes
- Within 5 minutes
- Within 10 minutes
- Within 15 minutes
- Within 30 minutes
- Within 1 hour
### Escalation policy level
1. Open the escalation policy settings
Go to the [escalation policy](https://hyperping.com/docs/monitoring/escalation-policies) you want to configure.
2. Find the Alert grouping section
The same time window options are available as at the project level.
3. Select a time window
Pick one from the dropdown.
> **Escalation policy settings win**
>
> When both are configured, the escalation policy's alert grouping overrides the project setting.
## Rules and examples
### Down alerts
1. When the first monitor goes down, an alert is sent
2. Any other monitors that go down within the time window won't trigger alerts
3. The first monitor's UUID is stored to track which monitor initiated the alert group
#### Example
Monitor A goes down → Alert sent
Monitor B goes down (within window) → No alert
Monitor C goes down (within window) → No alert
### Up alerts
#### Within the time window
- Only the first alerted monitor can send an up alert
- Other monitors going up won't trigger alerts
#### Outside the time window
- First monitor to go up gets the alert
- Other monitors going up within the new window won't trigger alerts
#### Example
Monitor A goes down → Alert sent
Monitor B goes down (within window) → No alert
Monitor A goes up (within window) → Up alert sent
Monitor B goes up (within window) → No up alert
Monitor C goes up (after window) → Up alert sent
## Time window behavior
- Each alert type (up/down) has its own independent window
- Windows are tracked separately for each project/escalation policy
#### Example with 60-second window
10:00:00 - Monitor A goes down → Alert sent
10:00:30 - Monitor B goes down → No alert
10:01:00 - Monitor A goes up → Up alert sent
10:01:30 - Monitor B goes up → No up alert
10:02:00 - Monitor C goes down → New down alert sent (window expired)
## Benefits
- Reduces alert noise during widespread issues
- Maintains visibility of the first affected monitor
- Prevents alert fatigue for teams
- Configurable at both project and escalation policy levels
- Independent windows for up and down alerts
## Best practices
- Set window duration based on your team's response time
- Consider enabling at escalation policy level for more granular control
- Monitor alert patterns to optimize window duration
- Use in conjunction with other alerting features like [alert delays](https://hyperping.com/docs/monitoring/edit-monitor) and repeat intervals
> **Want the grouped alert to escalate until someone responds?**
>
> Pair alert grouping with an [escalation policy](https://hyperping.com/docs/monitoring/escalation-policies) so the single alert still moves through Slack, SMS, and phone calls step by step.
## Next steps
[
Escalation policies→
Route alerts step by step until someone responds.
](https://hyperping.com/docs/monitoring/escalation-policies)[
On-call schedules→
Page whoever is on duty across rotations and timezones.
](https://hyperping.com/docs/monitoring/on-call)[
Edit a monitor→
Alert delays and per-monitor notification settings.
](https://hyperping.com/docs/monitoring/edit-monitor)[
Notification channels→
Email, SMS, phone calls, Slack, Teams and more.
](https://hyperping.com/docs/projects/notification-channels)
[](https://x.com/hyperping)[](https://www.linkedin.com/company/hyperping)
© 2026 Hyperping
---
Source: https://hyperping.com/docs/monitoring/healthchecks
# Healthchecks
Monitor your cron jobs and scheduled tasks, and get alerted when they fail to run.
Each healthcheck gives your job a unique URL to ping when it runs. If the ping does not arrive on schedule, Hyperping alerts you. Typical candidates: backups, system updates, log rotation, database maintenance, report generation, email jobs, automated tests, file cleanup, SSL renewal, and data synchronization.
Healthchecks watch jobs that run on a schedule. For a service that should answer continuously, use an [uptime monitor](https://hyperping.com/uptime-monitoring) instead.
A healthcheck's ping URL, status and execution history
## HTTP pings
Each healthcheck provides a unique endpoint upon creation, in this format: `https://hc.hyperping.io/TOKEN_ID`
At the end of your task, send a HEAD, GET or POST HTTP request to this endpoint to log the run. Any tool that can make an HTTP request works:
```bash
# Ping when your job completes successfully
curl -fsS https://hc.hyperping.io/TOKEN_ID
```
> **Ping only on success**
>
> In shells and crontabs, chain the ping after your command with `&&` so it only fires when the job exits successfully. A failing job never pings, and Hyperping alerts you once the grace period passes.
### Measure your job execution time
You can append `/start` to the URL to measure the job execution time. Hit this endpoint with a HEAD, GET or POST request at the beginning of your script, then ping the regular URL at the end:
```bash
# Signal the start of the job
curl -fsS https://hc.hyperping.io/TOKEN_ID/start
/usr/local/bin/backup.sh
# Signal completion
curl -fsS https://hc.hyperping.io/TOKEN_ID
```
## Grace period
Each healthcheck has a grace period: how long Hyperping waits from the moment it expects a ping before alerting you.
Use it to absorb normal variance in run time. If a script is expected to take 5 minutes, a 10 minute grace period avoids alerts for runs that are just a little slow.
## Schedules: simple or cron
Each healthcheck expects pings on a schedule. Two modes are supported:
### Simple mode
Set the interval at which you expect a ping: every 10 minutes, every hour, every day. If no ping arrives within the interval plus the grace period, you get alerted.
### Cron mode
For jobs that run on a precise schedule, use the same cron expression as the job itself, together with its timezone. Hyperping computes the expected run times from the expression and alerts you when a run is missed.
For example, a nightly backup running at 2:00 AM in Paris would use the expression `0 2 * * *` with the `Europe/Paris` timezone.
Both modes are also available programmatically via the [Healthchecks API](https://hyperping.com/docs/api/healthchecks).
## Integrations
When a healthcheck misses its ping, Hyperping opens an incident (_Name missed its scheduled ping_) and alerts every channel at once: email and SMS to every member of the project, Slack, Discord, Telegram, PagerDuty and Opsgenie. When the next ping arrives, the incident resolves and a recovery goes out on the same channels, and PagerDuty and Opsgenie alerts close on their own. See [Integrations](https://hyperping.com/docs/integrations) for setup.
> **Monitors only**
>
> Escalation policies, on-call schedules, Microsoft Teams, phone calls and webhooks apply to monitors, not to healthchecks. To page whoever is on call for a missed job, send healthcheck alerts to PagerDuty or Opsgenie.
## Rate limits
Healthcheck pings are limited in two ways:
### IP Rate limit
You cannot ping from the same IP more than 300 times per minute.
### Token Rate limit
You cannot ping a single check more than 10 times per minute.
## Guides by scheduler
Where the ping goes, and how each scheduler fails silently, depends on what runs the job. These guides give a tested setup for each:
- On a server: [systemd timers](https://hyperping.com/blog/how-to-monitor-systemd-timers), [Windows Task Scheduler](https://hyperping.com/blog/how-to-monitor-windows-task-scheduler), [Kubernetes CronJobs](https://hyperping.com/blog/how-to-monitor-kubernetes-cronjobs)
- On a platform: [GitHub Actions scheduled workflows](https://hyperping.com/blog/how-to-monitor-github-actions-scheduled-workflows), [Vercel cron jobs](https://hyperping.com/blog/how-to-monitor-vercel-cron-jobs), [Cloudflare Workers cron triggers](https://hyperping.com/blog/how-to-monitor-cloudflare-workers-cron-triggers)
- In the app: [Laravel scheduler](https://hyperping.com/blog/how-to-monitor-laravel-scheduler), [Rails scheduled jobs](https://hyperping.com/blog/how-to-monitor-rails-scheduled-jobs), [Node.js cron jobs](https://hyperping.com/blog/how-to-monitor-nodejs-cron-jobs), [Celery beat](https://hyperping.com/blog/how-to-monitor-celery-beat), [Sidekiq cron jobs](https://hyperping.com/blog/how-to-monitor-sidekiq-cron-jobs), [pg\_cron](https://hyperping.com/blog/how-to-monitor-pg-cron)
- By job: [database backups](https://hyperping.com/blog/how-to-monitor-database-backups), [a dead man's switch for Prometheus Alertmanager](https://hyperping.com/blog/how-to-monitor-prometheus-alertmanager), [scheduled AI agents](https://hyperping.com/blog/how-to-monitor-scheduled-ai-agents)
Coming from Opsgenie heartbeats? The [Opsgenie migration guide](https://hyperping.com/docs/migrate/from-opsgenie) recreates each one as a healthcheck. To write or check a schedule, use the [cron expression generator](https://hyperping.com/cron-expression-generator).
## Next steps
[
Healthchecks API→
Create, update, pause and resume healthchecks programmatically.
](https://hyperping.com/docs/api/healthchecks)[
Alert integrations→
Send healthcheck alerts to Slack, Discord, Telegram, PagerDuty and Opsgenie.
](https://hyperping.com/docs/integrations)[
Healthchecks on status pages→
Show a scheduled job next to your websites and APIs, with its uptime.
](https://hyperping.com/docs/status-page/add-services)[
Uptime monitors→
Monitor websites and APIs alongside your scheduled jobs.
](https://hyperping.com/docs/monitoring/create-monitor)
[](https://x.com/hyperping)[](https://www.linkedin.com/company/hyperping)
© 2026 Hyperping
---
Source: https://hyperping.com/docs/monitoring/keyword-monitoring
# Keyword monitoring
Keyword monitoring verifies that a page or API response actually contains the content you expect, not just that it responds. A monitor can return a 200 status code while serving an error page, an empty template, or a broken deploy. Checking for a keyword catches these silent failures.
This page covers the setup in Hyperping. For the wider picture, which failures a keyword check catches, where it stops being enough, and when to reach for a browser check instead, read [keyword monitoring: check content, not just uptime](https://hyperping.com/blog/keyword-monitoring).
> **Keyword check or browser check?**
>
> A keyword check asserts on the raw response body of an HTTP monitor, without executing JavaScript. If the text you want to verify only renders client-side, in a real browser, use a [browser check](https://hyperping.com/docs/monitoring/browser-checks) instead.
## How it works
On every check, Hyperping fetches the response body of your HTTP monitor and verifies that it includes the text you configured. If the text is missing, the monitor is considered down: we double-check from your other selected regions to rule out a false positive, then open an outage and alert your channels, exactly like a failed status code.
## Set up a keyword check
1. Create a new HTTP monitor or edit an existing one. See [Create a monitor](https://hyperping.com/docs/monitoring/create-monitor).
2. Open the advanced HTTP settings.
3. In **Text body assertion**, enter the text that the response body must include.
4. Save the monitor.
The check runs at your monitor's regular interval, from all the regions you selected.
## Choosing a good keyword
- **Pick stable text.** A footer mention, a product name in the hero, or a fixed JSON field name are good candidates.
- **Avoid dynamic content.** Timestamps, usernames, cart counts, or A/B tested copy will cause false alarms.
- **Keep it exact.** The response body must include the text exactly as you typed it.
- **For APIs, assert on structure.** A key like `"status":"ok"` validates that your endpoint returns real data, not an error payload.
## Common use cases
- **Soft errors:** catch error pages served with a 200 status code.
- **Deploy regressions:** detect a page that renders empty after a bad release.
- **CMS issues:** verify critical content is still published.
- **API contracts:** confirm an endpoint returns the expected payload, not just a response.
## Plan availability
Keyword monitoring is included on every plan, including the Free plan.
## Troubleshooting
If a keyword check fails unexpectedly, open the monitor's [logs](https://hyperping.com/docs/monitoring/logs) to inspect the actual response we received. Frequent causes are localized content, cookie or consent walls, and pages that only render the keyword client-side with JavaScript. For content that requires a real browser to render, use a [browser check](https://hyperping.com/docs/monitoring/browser-checks) instead.
## Next steps
[
Create a monitor→
All monitor settings: protocols, regions, intervals, and the Text body assertion field.
](https://hyperping.com/docs/monitoring/create-monitor)[
Monitor logs→
Inspect the exact response Hyperping received on every check.
](https://hyperping.com/docs/monitoring/logs)[
Browser checks→
Run Playwright scripts for content that only renders with JavaScript.
](https://hyperping.com/docs/monitoring/browser-checks)[
DNS monitoring→
Query a DNS record and verify the answer matches what you expect.
](https://hyperping.com/docs/monitoring/dns)
[← Ping and port monitoring](https://hyperping.com/docs/monitoring/ping-port)[Browser checks →](https://hyperping.com/docs/monitoring/browser-checks)
[](https://x.com/hyperping)[](https://www.linkedin.com/company/hyperping)
© 2026 Hyperping
---
Source: https://hyperping.com/docs/monitoring/local-playwright-setup
# Run Playwright locally
Updated April 28, 2026
Mirror the Hyperping browser-check runtime on your laptop. Same Playwright version, same package set, same timeout cap, so a script that passes locally runs the same way in production. Pick the runtime that matches your monitor and follow the install for that version.
Default runtime
2026.05 · Node 24 · Playwright 1.59.1
Legacy runtime
2023.04 · Node 16 · Playwright 1.33
Browser
Chromium, headless
Run cap
2 minutes per run
> **Pick the runtime first**
>
> Open the monitor in Hyperping and check the runtime card. Install Playwright at the version that matches it, otherwise locator behavior, fixture syntax, and reporter output can drift between local and production.
## Install
### Runtime 2026.05
Node 24 with Playwright 1.59.1. Web Vitals are collected by the runtime, so they only appear once the check runs in Hyperping.
TerminalBASH
```
mkdir hyperping-browser-checks
cd hyperping-browser-checks
npm init -y
# Playwright versions used by the 2026.05 runtime
npm install playwright@1.59.1 @playwright/test@1.59.1
# Same package set as the runtime
npm install typescript@^5.6 expect@^29 uuid@^9.0.1 \
lodash@4.17.21 moment@^2.30.1 axios@^1.13.2 \
btoa@1.2.1 jsonwebtoken@^9.0.2 date-fns@^2.30.0 crypto-js@^4.2.0
# Download Chromium
npx playwright install chromium
```
### Runtime 2023.04
Node 16 with Playwright 1.33. Use this only if the monitor is still on the 2023.04 runtime.
TerminalBASH
```
mkdir hyperping-browser-checks
cd hyperping-browser-checks
npm init -y
# Playwright versions used by the 2023.04 runtime
npm install playwright@1.33.0 @playwright/test@1.33.0
# Same package set as the runtime
npm install typescript@^5.0.4 expect@^27.5.1 uuid@^9.0.0 \
lodash@4.17.21 moment@^2.29.4 axios@^1.4.0 \
btoa@1.2.1 jsonwebtoken@^9.0.0 date-fns@^2.30.0 crypto-js@^4.1.1
# Download Chromium
npx playwright install chromium
```
## Configure Playwright
Match the run cap and the workers count Hyperping uses. The 2-minute global timeout is the most common gotcha, scripts that pass locally with no cap will fail in production when they sneak past 120 seconds.
playwright.config.jsJS
```
// playwright.config.js
const config = {
globalTimeout: 120 * 1000, // match Hyperping's 2-minute run cap
workers: 1,
expect: { timeout: 30 * 1000 },
projects: [
{
name: 'chromium',
use: {
viewport: { width: 1280, height: 720 },
deviceScaleFactor: 1,
defaultBrowserType: 'chromium',
},
},
],
};
export default config;
```
## Write your first test
Drop a script under `tests/` and run it. Playwright auto-detects `.spec.ts` and `.spec.js` files in that directory.
tests/example.spec.tsTS
```
// tests/example.spec.ts
import { test, expect } from '@playwright/test';
test('homepage renders', async ({ page }) => {
await page.goto('https://example.com');
await expect(page).toHaveTitle(/Example Domain/);
await expect(page.locator('h1')).toContainText('Example Domain');
});
```
## Run with a visible browser
Hyperping runs scripts headless. Locally you'll usually want a visible browser while you're authoring, so you can see exactly what the script does.
HeadedBASH
```
npx playwright test --headed
```
For step-by-step debugging, open the Playwright Inspector:
DebugBASH
```
npx playwright test --debug
```
After a run, the HTML report shows traces, screenshots, and the step tree:
ReportBASH
```
npx playwright show-report
```
## Environment variables
Hyperping injects environment variables at run time and exposes them as `process.env.NAME`. Mirror that locally with a `.env` file or shell exports so the same script works in both places.
.envBASH
```
# .env
EMAIL=test@example.com
PASSWORD=changeme
API_TOKEN=...
BASE_URL=https://staging.your-app.com
```
## Use the bundled package set
Lodash, moment, axios, date-fns, and the other libraries that ship with the runtime are all available in your script. Importing them locally with the same versions keeps the behavior identical.
cart.spec.tsTS
```
import { test, expect } from '@playwright/test';
import axios from 'axios';
test('cart roundtrip', async ({ page }) => {
test.setTimeout(120_000);
await page.goto(process.env.BASE_URL);
await page.click('[data-testid="add-to-cart"]');
await expect(page.locator('.cart-count')).toHaveText('1');
// Cross-check via the API
const { data } = await axios.get(`${process.env.BASE_URL}/api/cart`, {
headers: { Authorization: `Bearer ${process.env.API_TOKEN}` },
});
expect(data.items).toHaveLength(1);
});
```
## Available packages
### Runtime 2026.05 12 packages
`playwright`1.59.1
Browser automation API.
`@playwright/test`1.59.1
Test runner with fixtures, locators, and expect.
`typescript`^5.6
TypeScript compiler.
`expect`^29
Standalone Jest-style assertion library.
`uuid`^9.0.1
RFC4122 UUIDs.
`lodash`4.17.21
Array, object, and collection utilities.
`moment`^2.30.1
Date and time parsing and arithmetic.
`axios`^1.13.2
HTTP client for API cross-checks.
`btoa`1.2.1
Base64 encoding for Node.
`jsonwebtoken`^9.0.2
Sign and verify JWTs.
`date-fns`^2.30.0
Modular date utilities.
`crypto-js`^4.2.0
Hashes, HMAC, and symmetric ciphers.
### Runtime 2023.04 12 packages
`playwright`^1.33.0
Browser automation API.
`@playwright/test`1.33
Test runner.
`typescript`^5.0.4
TypeScript compiler.
`expect`^27.5.1
Standalone assertion library.
`uuid`^9.0.0
RFC4122 UUIDs.
`lodash`4.17.21
Utility functions.
`moment`^2.29.4
Date and time helpers.
`axios`^1.4.0
HTTP client.
`btoa`1.2.1
Base64 encoding for Node.
`jsonwebtoken`^9.0.0
JWT sign and verify.
`date-fns`^2.30.0
Modular date utilities.
`crypto-js`^4.1.1
Hashes, HMAC, ciphers.
## Move the script to Hyperping
1. Create a Browser monitor
In [app.hyperping.io](https://app.hyperping.io) click **New monitor**, pick **Browser**, and select the matching runtime.
2. Paste the script and add secrets
Copy the test body straight into the editor. Add every `process.env.NAME` reference under **Environment variables** in the settings panel.
3. Run, then schedule
Click **Run** to execute the script once on a Hyperping droplet. When it passes, save the monitor to put it on the schedule.
## Best practices
### Habits that survive the move to production 5 rules
`Stable selectors`role / data-testid
Use `getByRole` and `getByTestId` instead of CSS classes. Stylesheet rewrites won't break them.
`Auto-waiting assertions`expect()
`await expect(locator).toBeVisible()` retries on its own. Most `waitForTimeout` calls are unnecessary and add flake.
`Stay under 2 minutes`run cap
Split long journeys into separate checks. One mega-test fails the whole flow when one step times out.
`Secrets in env vars`process.env
Never paste tokens into the script body. Anything sensitive belongs in **Environment variables**.
`Log the values you watch`console.log
A `console.log` for latency, counts, or IDs lands in the run logs and makes post-mortem analysis easier.
## Next steps
[
Browser Checks→
Runtimes, Web Vitals, timeouts, environment variables, and the run-log format.
](https://hyperping.com/docs/monitoring/browser-checks)[
Playwright templates→
Twelve ready-to-paste scripts covering smoke, auth, search, checkout, performance, and more.
](https://hyperping.com/docs/monitoring/browser-check-templates)[
Datacenter regions→
Pick which probe regions run each check to cover the geographies that matter to your users.
](https://hyperping.com/docs/monitoring/datacenter-regions)[
Monitor logs→
Inspect the details of every check Hyperping performs on your monitors.
](https://hyperping.com/docs/monitoring/logs)
For locators, fixtures, expect, and the rest of the API, see the upstream [Playwright docs](https://playwright.dev/docs/writing-tests).
[← Browser Checks](https://hyperping.com/docs/monitoring/browser-checks)[Browser check templates →](https://hyperping.com/docs/monitoring/browser-check-templates)
[](https://x.com/hyperping)[](https://www.linkedin.com/company/hyperping)
© 2026 Hyperping
---
Source: https://hyperping.com/docs/monitoring/logs
# Monitor logs
Inspect every check Hyperping performs on a monitor: status code, response time, and the region it ran from. Use logs to see exactly what Hyperping received when an alert looks wrong.
Logs are useful when:
- You need to investigate a false positive and see what Hyperping actually received
- You want to compare response times across different regions
- You are debugging intermittent errors or slow responses
- You need to verify that a fix or deployment resolved an issue
The logs view shows each check with its status code, response time, and region
## Access logs
1. Open a monitor
Open the [Hyperping dashboard](https://app.hyperping.io) and click on a monitor.
2. Go to the Logs tab
It sits on the monitor's report page, at **/logs**.
## What logs capture
| Field | Description |
| --- | --- |
| Status code | The HTTP status code returned by the endpoint |
| Response time | Time in milliseconds from request to response |
| Location | The datacenter region that performed the check |
| Method | The HTTP method used for the request |
| Timestamp | When the check was performed |
## Use cases
### Debug false positives
If a monitor triggered an alert but your service seemed fine, check the logs to see what status code and headers Hyperping received. This often reveals issues like rate limiting, firewall blocks, or CDN errors that only affect external checks. See [false positives](https://hyperping.com/docs/monitoring/false-positives) for the common causes and their fixes.
### Verify monitor behavior
After changing a monitor's configuration (expected status code, regions, or assertions), use logs to confirm the checks are returning what you expect.
### Track regional performance
Compare response times across different regions to identify latency issues. If checks from one region consistently show higher response times, it could indicate a routing or infrastructure problem in that area.
> **Looking for trends instead of individual checks?**
>
> Logs show one check at a time. For latency graphs and spotting degradation over time, see [Response times](https://hyperping.com/docs/monitoring/response-times).
## Troubleshooting
**Logs show a different status code than expected**
Your endpoint may be returning redirects (301/302) or your server could be rate limiting Hyperping's requests. Check the response headers for `Location` or rate limit headers.
**Response times vary widely between regions**
This is normal if your server is located in a specific region. Checks from nearby datacenters will be faster. Consider adjusting your [selected regions](https://hyperping.com/docs/monitoring/datacenter-regions) to match where your users are.
**I do not see logs for a monitor**
Logs are generated with each check. If the monitor was just created, wait for the first check interval to pass. If the monitor is paused, no new logs will be generated.
## Next steps
[
Response times→
Track latency from your users' perspective and spot degradation.
](https://hyperping.com/docs/monitoring/response-times)[
Datacenter regions→
Where checks run from, and how regions rotate.
](https://hyperping.com/docs/monitoring/datacenter-regions)[
Uptime reports→
Uptime, outages, MTTA and MTTR across your monitors.
](https://hyperping.com/docs/monitoring/reports)[
Edit a monitor→
Change check settings or alert timing at any time.
](https://hyperping.com/docs/monitoring/edit-monitor)
[← Healthchecks](https://hyperping.com/docs/monitoring/healthchecks)[Response times →](https://hyperping.com/docs/monitoring/response-times)
[](https://x.com/hyperping)[](https://www.linkedin.com/company/hyperping)
© 2026 Hyperping
---
Source: https://hyperping.com/docs/monitoring/on-call
# On-call
Create on-call schedules so alerts reach whoever is on duty, not the whole team. Each schedule can contain multiple rotations with their own timezones, so teams across regions like the US, Europe, and India fit in a single schedule view.
> **Before you start**
>
> Rotations are built from the teammates in your project. [Invite your teammates](https://hyperping.com/docs/projects/teammates) first so you can add them to a rotation.
The on-call schedules list, with escalation policy indicators.
## Accessing On-call
Go to [On-Call](https://app.hyperping.io/oncall-schedules) in the left sidebar of the Hyperping app. You'll see a list of existing schedules with indicators showing which ones are linked to escalation policies.
**URL:** `https://app.hyperping.io/oncall-schedules`
## Create a new on-call schedule
1. Start a new schedule
Click **New on-call schedule** at the top right.
2. Name your schedule
The schedule will contain all your rotations.
3. Add a rotation
Each rotation has its own settings:
- **Rotation name:** E.g., "US Team", "Europe Team", "India Team"
- **Timezone:** Each rotation has its own timezone setting
- **Add users:** Select teammates for this specific rotation
- **Start date & time:** When this rotation begins
- **Handoff time:** The daily time when shifts change for this rotation
- **Concurrent shifts:** Number of people on-call simultaneously in this rotation
- **Rotation type:** Daily, weekly, etc.
- **Time restrictions:** (Optional) Hours when this rotation is active
- **Rotation order:** Drag and drop to set user order within this rotation
4. Add more rotations
Repeat for each team or timezone that needs its own rotation.
5. Preview
See a unified calendar view of all rotations before saving.
6. Save
Click **Save Schedule** to activate.
Rotation settings for cadence, handoff time, concurrent coverage, and the live two-week preview.
A global schedule with three regional rotations, a two-week timeline, and full coverage.
## Managing on-call schedules
After creating a schedule, you can view all rotations in a unified timeline, see who is currently on-call across all teams, and manage individual rotations independently.
- **On call now:** See which users are currently on-call across all rotations.
- **Escalation policy indicator:** Schedules show whether they're linked to any escalation policies.
- **Add/remove rotations:** Create new rotations or delete existing ones.
- **Edit individual rotations:** Each rotation can be configured independently with its own timezone, users, and settings.
- **Unified timeline view:** See all rotations from different timezones in one calendar view.
- **Preview:** Always check the updated rotation schedule before saving changes.
## Using on-call schedules in escalation policies
Connect a schedule to an [escalation policy](https://hyperping.com/docs/monitoring/escalation-policies) so alerts go to whoever is currently on-call:
1. Open Escalation Policies
Go to **Escalation Policies** in the sidebar, then create a new policy or edit an existing one.
2. Pick the notification type
When setting up escalation steps, you can select an on-call schedule for email, SMS, or phone call notifications.
3. Select the schedule
In the recipient dropdown, your on-call schedules are listed under the "On-Call Schedules" section. Notifications will be sent to whoever is currently on-call across all rotations in that schedule.
With this setup, alerts are sent to the team members who are actively on-call at the time of the incident, automatically coordinating across different timezones and rotations.
> **Paged once per monitor during a widespread outage?**
>
> Enable [grouped alerts](https://hyperping.com/docs/monitoring/grouped-alerts) so related incidents within a time window send a single alert instead of one page per monitor.
## Multi-timezone coordination
The multi-rotation feature is particularly powerful for global teams:
- **Regional handoffs:** Set up rotations for different regions with appropriate local times.
- **Unified view:** See all rotations in one timeline while respecting individual timezone settings.
## Overrides and substitutions
Vacations, sick days, and swapped shifts happen.
**A teammate is unavailable for their shift**
Temporarily reassign the shift to another teammate, without rebuilding the whole rotation.
**Who gets paged after I change the schedule?**
Escalation policies resolve the schedule at alert time: whoever is on call after your change is the one who gets paged.
## Best practices
- Use **multiple rotations** to organize teams by region or expertise area.
- Set appropriate **timezones** for each rotation to match local business hours.
- Use **concurrent shifts** within rotations for critical services to ensure redundancy.
- Regularly review rotation orders and team assignments as your organization grows.
- Use **time restrictions** per rotation to avoid alerting during regional off-hours.
## Next steps
[
Escalation policies→
Route alerts step by step until someone responds.
](https://hyperping.com/docs/monitoring/escalation-policies)[
Grouped alerts→
One alert when multiple monitors fail within a time window.
](https://hyperping.com/docs/monitoring/grouped-alerts)[
Invite teammates→
Add the people you want in your rotations.
](https://hyperping.com/docs/projects/teammates)[
Notification channels→
Email, SMS, phone calls, Slack, Teams and more.
](https://hyperping.com/docs/projects/notification-channels)
[](https://x.com/hyperping)[](https://www.linkedin.com/company/hyperping)
© 2026 Hyperping
---
Source: https://hyperping.com/docs/monitoring/operational-faq
# Operational FAQ
Quick answers to the operational questions our support team hears most often. Regions, false positives, phone numbers, rate limits, and check behavior, all in one place.
## From which regions do checks run?
Checks run from 18 regions across 7 global zones: North America, South America, Europe, Asia, Australia, the Middle East, and Africa. See the full list in [Datacenter regions](https://hyperping.com/docs/monitoring/datacenter-regions).
Each check runs from one region at a time, rotating through the regions you selected for the monitor. The probes run on a mix of hosting providers (AWS, Scaleway, DigitalOcean) for redundancy.
**See all 18 regions by zone**
- **North America**: San Francisco, N. Virginia, N. California, New York City, Toronto
- **South America**: São Paulo
- **Europe**: London, Paris, Frankfurt, Amsterdam
- **Asia**: Seoul, Mumbai, Bangalore, Singapore, Tokyo
- **Australia**: Sydney
- **Middle East**: Bahrain
- **Africa**: Cape Town
## How does Hyperping avoid false positives?
Every failure is double-checked before you hear about it. When a check fails, Hyperping immediately re-runs it from every other region you selected, and only confirmed failures open an outage and trigger alerts.
The probes also run on a mix of hosting providers (AWS, Scaleway, DigitalOcean), so an isolated network blip at one provider never becomes a fake incident.
> **A single server having a bad moment never pages you**
>
> Multi-region double-checks plus provider redundancy mean alerts only fire on real, confirmed outages. See [false positives](https://hyperping.com/docs/monitoring/false-positives) for the confirmation flow and what to check when an alert still looks wrong.
## What phone numbers do alert calls come from?
If you have a European phone number, calls come from **+31 970 10 25 72 04**. For US and non-EU countries, calls come from **(424) 325-7650** (+14243257650).
Save both numbers as a contact named Hyperping so on-call engineers recognize the call and their phone does not silence it. Phone calls are enabled through an [escalation policy](https://hyperping.com/docs/monitoring/escalation-policies), see the [phone call integration](https://hyperping.com/docs/integrations/phonecall) for setup and throttling details.
## How often can I ping a healthcheck?
Healthcheck endpoints have two rate limits:
- **Per IP**: you cannot ping from the same IP more than 300 times per minute.
- **Per check**: you cannot ping a single check more than 10 times per minute.
Each healthcheck gets a unique endpoint in the format `https://hc.hyperping.io/TOKEN_ID`. Hit it with a HEAD, GET or POST request at the end of your job. See [Healthchecks](https://hyperping.com/docs/monitoring/healthchecks) for schedules and grace periods.
```bash
# Ping your healthcheck at the end of a job (HEAD, GET or POST)
curl https://hc.hyperping.io/TOKEN_ID
```
## What SSL errors are detected?
SSL monitoring is enabled by default for all HTTPS monitors, with expiry reminders at the threshold you choose. Hyperping automatically detects and reports these certificate issues:
- **Expired** or **not yet valid**: the certificate, or an intermediate it relies on, is outside its validity dates.
- **Hostname mismatch**: none of the names in the certificate covers the monitored host.
- **Self-signed**, **untrusted root** or **invalid chain**: browsers can't trace the certificate back to an authority they trust.
- **Incomplete chain**: the server doesn't send the intermediate certificates.
- **Revoked**: the issuer revoked the certificate (checked with OCSP and revocation lists).
- **Outdated TLS**, **weak signature** or **weak key**: TLS 1.0/1.1 only, SHA-1/MD5 signatures, short keys.
Certificates are checked daily, and you can recheck one from the monitor's certificate details after renewing. See [SSL monitoring](https://hyperping.com/docs/monitoring/ssl). For the registration itself, see [domain expiry monitoring](https://hyperping.com/docs/monitoring/domain-expiry).
## What are the API rate limits?
By default, every project is limited to 800 API requests per hour, calculated on a rolling window. Each project has its own separate quota, tracked by API token, with a per-IP fallback when no valid token is provided.
When you exceed the limit, the API returns `429 Too Many Requests` with a `retry-after` header, and every response includes a `ratelimit` header so you can track your usage. Paid plans can request higher limits from support. Full details in [API rate limits](https://hyperping.com/docs/monitoring/api-rate-limits).
## What are the browser check limits?
Each browser check runs a Playwright script in headless Chromium with a 2-minute global timeout per run. Individual tests inherit Playwright's 30-second default timeout, which you can override with `test.setTimeout`.
Double check is enabled by default: a failed run is immediately retried from a different region before an outage opens. Every run keeps its logs, screenshots, video, and trace indefinitely. Long flows are usually better split into separate checks, one per critical path. See [Browser checks](https://hyperping.com/docs/monitoring/browser-checks).
## Next steps
[
Datacenter regions→
The full list of 18 regions and how checks rotate through them.
](https://hyperping.com/docs/monitoring/datacenter-regions)[
Escalation policies→
Route alerts in order, with delays, until resolved.
](https://hyperping.com/docs/monitoring/escalation-policies)[
Healthchecks→
Monitor cron jobs and scheduled tasks that must never fail silently.
](https://hyperping.com/docs/monitoring/healthchecks)[
How we calculate uptime→
What counts as up, what counts as down, and the math behind the number.
](https://hyperping.com/docs/status-page/uptime-calculation)
[← Monitoring overview](https://hyperping.com/docs/monitoring)[Datacenter regions →](https://hyperping.com/docs/monitoring/datacenter-regions)
[](https://x.com/hyperping)[](https://www.linkedin.com/company/hyperping)
© 2026 Hyperping
---
Source: https://hyperping.com/docs/monitoring/ping-port
# Ping (ICMP) and TCP port monitoring
Monitor any host or network service that doesn't speak HTTP, and get alerted the moment it stops responding.
[HTTP monitors](https://hyperping.com/uptime-monitoring) cover websites and APIs, but plenty of infrastructure never answers an HTTP request: bare servers, databases, mail servers, game servers, VPN endpoints. Ping and port monitors cover these cases. (ICMP itself has no port number; if you are configuring a firewall for it, see [why ping has no port and what to open](https://hyperping.com/blog/icmp-port-number).) A ping (ICMP) monitor tells you whether a host is reachable at all. A port monitor tells you whether a specific service on that host is accepting connections.
Use them when you want to know that:
- A server or network appliance is up and reachable, independently of any web service it runs.
- A database, cache, or mail server is accepting connections on its port.
- A game server or any custom TCP service is listening where clients expect it.
## Create a ping (ICMP) monitor
1. Open the new monitor form
Go to your [dashboard](https://app.hyperping.io) and click the **New monitor** card.
2. Name the monitor
Give it a readable name, for example "DB server" or "Office gateway".
3. Select the ICMP protocol
Choose **ICMP** in the protocol list.
4. Enter a hostname or IP address
For example `db.example.com` or `203.0.113.10`. Don't include `http://` or `https://`, those prefixes are for HTTP monitors.
5. Save
The first check runs immediately and you're redirected to the monitor's detailed view.
ICMP performs a simple echo request, commonly called a ping. The host either returns an echo response, in which case it's considered up, or it doesn't, in which case the check fails. There's nothing else to configure: no status codes, no request bodies.
> **Host up but pings failing?**
>
> Some networks and cloud firewalls block ICMP entirely. If your host is up but pings are filtered, the monitor will report it as down. In that case, monitor a TCP port instead.
A ping monitor: name, IP address, and the ICMP protocol selected
## Create a port monitor
1. Open the new monitor form
Go to your [dashboard](https://app.hyperping.io) and click the **New monitor** card.
2. Select the Port protocol
Choose **Port** in the protocol list.
3. Enter a hostname or IP address
The same way as for ICMP.
4. Enter the port number
For example `5432` for PostgreSQL. The port is required for this protocol.
5. Save
Checks start right away.
A port monitor attempts a TCP connection to the given host and port. If the connection is accepted, the service is considered up. If it's refused or times out, the check fails and, once confirmed, alerts go out.
## Regions and check intervals
Ping and port monitors use the same regions and scheduling as every other monitor. Checks are performed from one selected region at a time, rotating between them:
1. Minute 1: check from Paris: OK
2. Minute 2: check from Frankfurt: OK
3. Minute 3: check from London: not OK. Hyperping immediately double-checks from the other selected regions. If they all fail too, the downtime is confirmed and alerts are sent.
This double-checking matters for network-level monitors: a single region can lose a route to your host while the rest of the internet reaches it fine. Requiring confirmation from other regions filters out these localized blips.
The default check interval is 30 seconds. Selecting [regions](https://hyperping.com/docs/monitoring/datacenter-regions) close to your infrastructure keeps latency measurements meaningful, since checks from far away include the round trip in their timings.
Ping and port monitors can also run over IPv6: switch **IP version** to **IPv6** in the monitor's advanced settings, or pass `"ip_version": 6` through the API. See [IP version](https://hyperping.com/docs/monitoring/create-monitor#ip-version).
> **Plan availability**
>
> Going lower than 30 seconds requires a Business or Enterprise plan.
## Common examples
| Service | Protocol | Port |
| --- | --- | --- |
| SMTP (mail server) | Port | 25 or 587 |
| PostgreSQL | Port | 5432 |
| Redis | Port | 6379 |
| SSH | Port | 22 |
| Server or gateway reachability | ICMP | n/a |
Only expose and monitor ports that are meant to be reachable from the internet. If your database only listens on a private network, Hyperping's pingers won't be able to reach it, and it's usually better kept that way.
## Limitations compared to HTTP monitors
Ping and port monitors check reachability, not correctness. The HTTP advanced settings don't apply here: there's no expected status code and no text body assertion. A port monitor will happily report your database as up as long as something accepts the TCP connection, even if the service behind it is misbehaving.
Two ways to close that gap:
- If the service has any HTTP surface, such as an admin endpoint or a health endpoint, prefer an HTTP monitor with an [expected status code or body assertion](https://hyperping.com/docs/monitoring/create-monitor).
- For correctness checks that only your own code can perform, run a periodic script that queries the service and pings a [healthcheck](https://hyperping.com/docs/monitoring/healthchecks) on success. You get alerted when the script stops reporting in.
## API and Terraform
Both monitor types are available through the [create monitor API](https://hyperping.com/docs/api/monitors/create). Set `protocol` to `icmp` or `port`, pass the hostname in `url`, and include the `port` number when the protocol is `port`:
```bash
curl -X POST https://api.hyperping.io/v1/monitors \
-H "Authorization: Bearer ${API_TOKEN}" \
-H "Content-Type: application/json" \
-d '{
"name": "PostgreSQL primary",
"url": "db.example.com",
"protocol": "port",
"port": 5432,
"regions": ["paris", "frankfurt", "london"],
"check_frequency": 30
}'
```
If you manage your monitoring as code, the [Terraform provider](https://hyperping.com/integrations/terraform) exposes the same fields on the `hyperping_monitor` resource.
## Next steps
[
Healthchecks→
Get alerted when a cron job or background script stops reporting in.
](https://hyperping.com/docs/monitoring/healthchecks)[
DNS monitoring→
Catch expired domains and hijacked records before your users do.
](https://hyperping.com/docs/monitoring/dns)[
Escalation policies→
Route alerts in order, with delays, until resolved.
](https://hyperping.com/docs/monitoring/escalation-policies)[
Create monitor API→
Every monitor field, scriptable from your own tooling.
](https://hyperping.com/docs/api/monitors/create)
[← How to create a monitor](https://hyperping.com/docs/monitoring/create-monitor)[Datacenter regions →](https://hyperping.com/docs/monitoring/datacenter-regions)
[](https://x.com/hyperping)[](https://www.linkedin.com/company/hyperping)
© 2026 Hyperping
---
Source: https://hyperping.com/docs/monitoring/quickstart
# Monitoring quickstart
Create your first monitor and get alerted on downtime, in under 2 minutes.
> **Before you start**
>
> You need a Hyperping account. [Create one for free](https://app.hyperping.io/register): no credit card required.
1. Create a monitor
From your [dashboard](https://app.hyperping.io), click **New monitor**. Give it a name (like "Website") and enter the URL to check. An IP address works too. Hit **Save**.
2. You're already covered
Your monitor is now checked every 30 seconds from multiple regions, and down or up alerts go to your signup email automatically. Nothing else to configure.
3. Add the channels your team actually watches
Connect Slack, SMS, phone calls or webhooks from your [notification channels](https://hyperping.com/docs/projects/notification-channels), and invite [teammates](https://hyperping.com/docs/projects/teammates) so they get alerted too.
## Prefer the API?
The same monitor, created programmatically:
```bash
curl -X POST https://api.hyperping.io/v1/monitors \
-H "Authorization: Bearer ${API_TOKEN}" \
-H "Content-Type: application/json" \
-d '{
"name": "Website",
"url": "https://acme.com",
"protocol": "http",
"check_frequency": 30,
"regions": ["paris", "london", "virginia"]
}'
```
**Response201 Created**
```json
{
"name": "Website",
"url": "https://acme.com",
"paused": false,
"regions": ["paris", "london", "virginia"],
"http_method": "GET",
"check_frequency": 30,
"uuid": "mon_3GhAQMYGEQuyUH",
"status": "up",
"ssl_expiration": 90,
"alerts_wait": 0
}
```
See the [Monitors API](https://hyperping.com/docs/api/monitors) for every field, or the [Terraform provider](https://hyperping.com/docs/community/terraform) to manage monitors as code.
## Manage your monitor
Everything is editable after creation: [edit its settings](https://hyperping.com/docs/monitoring/edit-monitor), pause its checks, or [delete it](https://hyperping.com/docs/monitoring/delete-monitor) along with its history.
## Troubleshooting
**My monitor shows down, but the site loads in my browser**
Open the monitor's [logs](https://hyperping.com/docs/monitoring/logs) to see the exact response we received. The usual causes: the endpoint returns a status code outside 200-299 (set an [expected status code](https://hyperping.com/docs/monitoring/create-monitor)), redirects are not followed, or a text body assertion no longer matches.
**No data after saving**
Saving triggers the first check immediately. If nothing shows after a minute, verify the URL is reachable from the public internet and includes http:// or https://.
## Next steps
[
All monitor settings→
Protocols, regions, intervals, and advanced HTTP options.
](https://hyperping.com/docs/monitoring/create-monitor)[
Escalation policies→
Decide who gets paged, in what order, until acknowledged.
](https://hyperping.com/docs/monitoring/escalation-policies)[
Create a status page→
Show your uptime to users on your own domain.
](https://hyperping.com/docs/status-page/create-status-page)[
Monitor cron jobs→
Catch scheduled tasks that fail silently.
](https://hyperping.com/docs/monitoring/healthchecks)
[](https://x.com/hyperping)[](https://www.linkedin.com/company/hyperping)
© 2026 Hyperping
---
Source: https://hyperping.com/docs/monitoring/reports
# Uptime reports
Track uptime, outages, MTTA and MTTR across your monitors, and export the numbers for SLA reviews. To convert an SLA percentage into the downtime it allows, use the [SLA and uptime calculator](https://hyperping.com/sla-calculator).
The reporting dashboard aggregates your monitoring data into per-monitor statistics: uptime percentage, outage counts, total downtime, and recovery metrics like [MTTR and MTTA](https://hyperping.com/glossary/mttr). It gives you both a high-level view across all monitors and the ability to drill down into specific incidents or timeframes.
Reports are useful when:
- You need to prove uptime to a customer or auditor as part of an [SLA](https://hyperping.com/glossary/sla)
- You run a monthly or quarterly reliability review with your team
- You are writing a postmortem and need exact outage counts and durations
- You want to track how quickly your on-call team acknowledges and resolves incidents
## Access the reporting dashboard
1. Open the Reporting section
Open the [Hyperping dashboard](https://app.hyperping.io/reporting/outages) and click **Reporting** in the left sidebar.
2. Set the period and filters
Adjust the report period to the timeframe you want to review, and filter down to the monitors or incidents you care about.
The Incidents report: daily incident counts, totals, and the incident log
## What the report shows
| Metric | Description |
| --- | --- |
| Uptime (SLA) | Percentage of time the monitor was up during the selected period |
| Outages | Number of outages, total downtime, and the longest outage in the period |
| MTTR | Mean Time to Recovery: how long it takes on average to resolve an outage |
| MTTA | Mean Time to Acknowledge: how long it takes on average for a team member to acknowledge an alert |
The dashboard also keeps a complete outage history you can browse and filter, so every number in the report can be traced back to the individual incidents behind it.
## Uptime SLA reporting
If your contracts include an availability commitment, the report gives you the evidence. Set the report period to your contractual reporting window, typically a calendar month or quarter, and read the uptime percentage per monitor. A 99.9% monthly target allows roughly 43 minutes of downtime, so the outage breakdown shows exactly where that budget went.
Because Hyperping checks your services from the outside, these numbers reflect what your customers actually experienced, which is what auditors and customers ask for in SLA reviews.
> **Plan availability**
>
> The reporting dashboard, the MTTA, MTTR and other KPIs, CSV export, and uptime SLA reporting are included in all paid plans, starting with Essentials. See the [pricing page](https://hyperping.com/pricing) for details.
## Weekly email reports
Hyperping can also send you a weekly report by email: a recurring summary of how your monitors performed over the past week, so your team gets the numbers without opening the dashboard. Weekly reports are available on every plan, including Free. If you would rather not receive them, you can turn them off from your settings in the dashboard.
## Export to CSV
You can download your metrics in CSV format for custom analysis. The export respects the filters you applied, so you can hand a customer the exact period covered by their SLA, or pull outage data into a spreadsheet for a postmortem.
Common uses:
- Attaching uptime evidence to an SLA review or compliance audit
- Building custom charts in a spreadsheet or BI tool
- Archiving monthly reliability numbers alongside your postmortems
## Pull reports programmatically
The same data is available through the [Reports API](https://hyperping.com/docs/api/reports). It returns SLA, MTTR and outage data for all monitors in your project, or for a single monitor:
```bash
curl https://api.hyperping.io/v2/reporting/monitor-reports \
-H "Authorization: Bearer ${API_TOKEN}"
```
**Response200 OK**
```json
{
"period": {
"from": "2025-04-30T23:28:48.404Z",
"to": "2025-05-06T23:28:48.404Z"
},
"monitors": [
{
"uuid": "mon_e3nJvpusxl6l3C",
"name": "Website",
"protocol": "http",
"sla": 99.184,
"outages": {
"count": 2,
"totalDowntime": 4231,
"totalDowntimeFormatted": "1hr 10min 31s"
},
"mttr": 2116,
"mttrFormatted": "35min 16s"
}
]
}
```
Pass `from` and `to` query parameters in ISO 8601 format to set the period. Without them, the report covers the last 7 days. The response includes each monitor's `sla`, outage counts and durations, and `mttr`, so you can feed the numbers into your own dashboards or scheduled SLA jobs. Your API token is available in the [Developers tab](https://app.hyperping.io/project/developers) of your project settings.
## Query reports from AI assistants
If you use Claude, Cursor, or another assistant that supports MCP, you can connect it to the [Hyperping MCP server](https://hyperping.com/docs/mcp) and ask for these numbers in plain language. The server exposes reporting tools like `get_monitor_uptime`, `get_monitor_mttr` and `get_monitor_mtta`, so questions like "what was our uptime last month" or "which monitor has the worst MTTR" get answered from your live data.
## Next steps
[
Reports API→
The full endpoint reference for programmatic reporting.
](https://hyperping.com/docs/api/reports)[
Response times→
Latency trends per region, from your customers' perspective.
](https://hyperping.com/docs/monitoring/response-times)[
Monitor logs→
The individual checks behind every uptime number.
](https://hyperping.com/docs/monitoring/logs)[
MCP server→
Ask for uptime and MTTR numbers from AI assistants.
](https://hyperping.com/docs/mcp)
[← Response times](https://hyperping.com/docs/monitoring/response-times)[API Rate Limits →](https://hyperping.com/docs/monitoring/api-rate-limits)
[](https://x.com/hyperping)[](https://www.linkedin.com/company/hyperping)
© 2026 Hyperping
---
Source: https://hyperping.com/docs/monitoring/response-times
# Response time monitoring
Track how fast your endpoints respond from your customers' perspective, and spot degradation before it becomes an outage.
Every check Hyperping performs on a monitor records a response time, measured in milliseconds from request to response. Checks run from datacenters around the world, so the numbers reflect what users in each region actually experience rather than what your servers report from the inside. For a one-off check without creating a monitor, [check any URL from 17 regions](https://hyperping.com/is-my-site-down).
Response time data is useful when:
- You want to confirm that a deployment did not slow down your API
- You suspect users in one region are getting slower responses than others
- You want to catch gradual degradation before it turns into downtime
- You need latency numbers to back up a conversation about performance
## What Hyperping measures
Each check produces one response time data point, tagged with the region that ran it. Checks run at the frequency you configure on the monitor, from every 10 seconds up to every 24 hours, so a frequent check builds a dense picture of your endpoint's latency throughout the day.
Hyperping aggregates these data points by region and continent on the monitor's report page. The raw check-by-check records remain available in the [monitor logs](https://hyperping.com/docs/monitoring/logs).
A monitor page: response time per zone, per-region logs, and the HTTP breakdown
## Read the response time graphs
1. Open a monitor
Open the [Hyperping dashboard](https://app.hyperping.io) and click on a monitor.
2. Review the graphs
The monitor's report page shows response time graphs alongside its uptime data, aggregated by continent and region.
A few patterns worth recognizing:
| Pattern | What it usually means |
| --- | --- |
| Step change after a deploy | A code or infrastructure change introduced a regression |
| Slow rise over days or weeks | Growing load or data volume is pushing your service toward its limits |
| Isolated spikes | Transient events such as scheduled jobs, backups, or garbage collection pauses |
| One region consistently elevated | A routing or infrastructure problem specific to that geography |
## Spot regional slowness
Hyperping checks from 18 locations across North America, Europe, Asia, Oceania, and South America. Because every data point carries its region, you can compare geographies directly and find degradation that only affects part of your audience.
> **Some variation between regions is normal**
>
> Checks from datacenters close to your servers will always be faster than checks from the other side of the world. What matters is change: a region that used to sit at a stable baseline and now runs consistently higher deserves a look at your CDN, DNS, or routing for that area.
If the regions being checked do not match where your users are, adjust them from the monitor's settings. See [Datacenter regions](https://hyperping.com/docs/monitoring/datacenter-regions) for the full list of available locations.
## Drill into individual checks
Graphs show the trend; logs show the evidence. When a graph reveals a spike or a slow region, open the **Logs** tab on the monitor's report page to see the individual checks behind it, each with its status code, response time, region, and timestamp.
This is the fastest way to answer questions like "was that spike one slow check or twenty?" or "did the slow responses also return errors?". See [Monitor logs](https://hyperping.com/docs/monitoring/logs) for the full field reference.
## Uptime monitoring vs performance monitoring
Response time data from Hyperping tells you how your service behaves from the outside: whether it responds, how fast, and from where. It reflects the full path a real request travels, including DNS, TLS, CDN, and network transit.
It does not tell you why your service is slow. Internal metrics such as database query times, per-route latency, error rates, and resource consumption belong to application performance monitoring (APM). The two are complementary: Hyperping tells you that something is slow or down before your customers notice, and your APM helps you find the cause.
## Track trends and export data
The report page graphs cover trend analysis for day-to-day work. For programmatic reporting, the [Reports API](https://hyperping.com/docs/api/reports) returns SLA, MTTR, and outage data for every monitor in your project:
```bash
curl https://api.hyperping.io/v2/reporting/monitor-reports \
-H "Authorization: Bearer ${API_TOKEN}"
```
Pull the numbers into your own dashboards or share them with stakeholders alongside the response time graphs.
## Query response times from AI assistants
Hyperping's MCP server lets AI assistants query your monitoring data directly. The `get_monitor_response_time` tool returns the latency trend for your monitors, so you can ask questions like "did checkout get slower this week?" in plain language and get an answer backed by real check data.
The related `get_monitor_anomalies` tool flags latency spikes automatically. See the [MCP server documentation](https://hyperping.com/docs/mcp) for setup and the full tool reference.
## Next steps
[
Monitor logs→
The check-by-check records behind every graph.
](https://hyperping.com/docs/monitoring/logs)[
Uptime reports→
Uptime, outages, MTTA and MTTR across your monitors.
](https://hyperping.com/docs/monitoring/reports)[
Datacenter regions→
Choose where in the world your checks run from.
](https://hyperping.com/docs/monitoring/datacenter-regions)[
MCP server→
Query your monitoring data from AI assistants.
](https://hyperping.com/docs/mcp)
[← Logs](https://hyperping.com/docs/monitoring/logs)[Uptime reports →](https://hyperping.com/docs/monitoring/reports)
[](https://x.com/hyperping)[](https://www.linkedin.com/company/hyperping)
© 2026 Hyperping
---
Source: https://hyperping.com/docs/monitoring/ssl
# SSL Monitoring
Get alerted before your SSL certificate expires, and as soon as it starts failing for your visitors. Hyperping checks the certificate of every HTTPS monitor once a day, with no extra setup. For an overview of the feature, see [SSL monitoring](https://hyperping.com/ssl-monitoring).
The SSL certificate panel of a monitor: days left, the alert window, and every check
> **Enabled by default**
>
> Every HTTPS monitor is checked, along with port monitors on ports that speak TLS directly: 443, 7443, 8443, 9443, 4443, 10443, 6443, 2083, 2087, 8006, 993, 995, 465, 636, 8883 and 5986. A URL with a custom port, like `https://example.com:8443`, is checked on that port.
## What is checked
Each check opens one TLS connection, the way a browser would, and verifies what the server actually serves. A certificate your provider renewed but your server doesn't serve yet still counts as expiring.
| Check | Fails when |
| --- | --- |
| **Expired** | The certificate, or an intermediate the server relies on, is past its end date. |
| **Not yet valid** | The start date is in the future (often a server clock problem, or a certificate installed too early). |
| **Hostname mismatch** | None of the names in the certificate covers the monitored host. Wildcards and IP addresses are matched the way browsers match them. |
| **Self-signed** | The certificate signs itself instead of being issued by an authority. |
| **Untrusted root** | The chain ends at an authority browsers don't trust, such as a private or internal CA. |
| **Incomplete chain** | The server doesn't send the intermediate certificates. Some browsers repair this on their own; curl, Android and most API clients don't. |
| **Invalid chain** | Any other reason the chain doesn't verify against the public trust store. |
| **Revoked** | The authority revoked the certificate. Checked with the response the server staples, the authority's OCSP responder, or its revocation list (CRL), which is what Let's Encrypt uses. |
| **Outdated TLS** | The server only offers TLS 1.0 or 1.1, which current browsers refuse. |
| **Weak signature** | The certificate or an intermediate is signed with SHA-1 or MD5. |
| **Weak key** | A key shorter than 2048-bit RSA (or 224-bit ECDSA). Shown on the monitor, never alerted. |
A failing check is spelled out in the panel, with what browsers will do about it
## Expiry alerts
In the monitor's **Notifications** tab, **SSL Expiry Alerts** sets how many days before expiry the first alert goes out: 1, 3, 7, 15, 30, 60 or 90 days, or never. With **Send reminders** on, a reminder follows at each step below it: with 30 days, alerts go out at 30, 15, 7, 3 and 1 days before expiry.
The SSL monitoring settings in the monitor's Notifications tab
- **Nothing is missed.** If a check couldn't run on the day a reminder was due, the reminder goes out on the next check, once.
- **No reminder after a renewal.** The certificate is read again right before a reminder is sent: if it was renewed in the meantime, nothing goes out. If you had already been warned, a **renewed** notice follows instead.
- **Who gets them.** Everyone on the project by email, plus the monitor's SSL notification channels (Slack, Microsoft Teams, Discord, Google Chat, Telegram, webhooks). PagerDuty and Opsgenie are only paged in the last 24 hours, and the renewal resolves the page.
> **60 or 90 days with short-lived certificates**
>
> Let's Encrypt and most automated certificates last 90 days. With a 60 or 90-day threshold, every renewal immediately falls inside the alert window. Keep those thresholds for certificates that last a year.
## Certificate error alerts
When a check finds a new problem, the monitor's SSL notification channels get an alert listing every issue on the certificate. When all problems are gone, they get a resolved notification. An issue that persists is not repeated every day, and an issue that was already there when the monitor was created is shown on the monitor but doesn't trigger an alert.
Pick the channels in the monitor's **Notifications** tab, under **SSL notification channels**.
## Certificate change notifications
Turn on **Certificate changes** to be told whenever the server starts serving a different certificate: a renewal, a new issuer, a new key. The notification shows the new and the previous certificate. It goes to the SSL channels, or to the team by email if the monitor has none. A load balancer or CDN that serves several certificates at once doesn't trigger it: a certificate seen in one of the last three checks doesn't count as new.
## Monitor list and certificate details
Each HTTPS monitor in the list shows the days left on its certificate, and a badge such as **CN Mismatch** when a check fails. Click **Filter**, then **Certificate errors**, and pick one type of error (expired, self-signed, hostname mismatch, revoked, incomplete chain…) or **Has any certificate error**.
Monitors filtered on a certificate error
On a monitor's **Overview**, the **SSL** button (with the days left) opens the **SSL certificate** panel:
- **Status and lifetime.** Valid, expiring or failing, the days left, and a bar from the issue date to the expiry date with the alert window marked. A warning appears when an automated certificate is past the point where it should have renewed.
- **Expiry alert.** When the first alert and the reminders will fire. **Change** opens the Notifications tab.
- **Checks.** Each check from the table above, with an explanation when it fails.
- **Hostnames covered**, **Details** (common name, issuer, validity, serial number, first seen) and the **Chain of trust** the server sends.
- **Domain registration**, when known: see [domain expiry monitoring](https://hyperping.com/docs/monitoring/domain-expiry).
## Refresh a certificate manually
Certificates are checked daily around 04:00 UTC. To read a renewed certificate right away:
1. Open your monitor
Go to the monitor whose certificate you renewed.
2. Open the certificate panel
On the **Overview** tab, click the **SSL** button.
3. Click Recheck
The panel refreshes with the certificate the server serves now. Alerts follow the same rules as the daily check. On a monitor with no certificate read yet, the button is called **Fetch certificate**.
## API and Terraform
The same settings are available on [monitors in the API](https://hyperping.com/docs/api/monitors/update): `ssl_alert_days` (-1 for never), `ssl_reminders` and `ssl_notify_on_change`. `ssl_expiration` is read-only: the whole days left before the certificate expires, rounded down, so a certificate expiring tomorrow afternoon shows `1`. The Terraform provider's `hyperping_monitor` resource takes the same three settings.
```bash
curl -X PUT https://api.hyperping.io/v1/monitors/mon_3GhAQMYGEQuyUH \
-H "Authorization: Bearer ${API_TOKEN}" \
-H "Content-Type: application/json" \
-d '{
"ssl_alert_days": 30,
"ssl_reminders": true,
"ssl_notify_on_change": true
}'
```
## Webhook payloads
Webhooks added as SSL channels receive certificate error alerts in the same shape as before:
```json
{
"event": "down",
"isDown": true,
"status": "SSL_ERRORS_DETECTED",
"sslEvent": true,
"domain": "https://example.com",
"alias": "Website",
"timestamp": "Oct 01 2026, 04:02:11 UTC"
}
```
Informational notices have their own `event` and always carry `"isDown": false`, so a consumer that acts on `event === "down"` ignores them: `ssl_expiring`, `ssl_renewed`, `ssl_changed`, `domain_expiring` and `domain_renewed`.
```json
{
"event": "ssl_expiring",
"isDown": false,
"status": "SSL_EXPIRING_SOON",
"sslEvent": true,
"monitorUuid": "mon_3GhAQMYGEQuyUH",
"domain": "https://example.com",
"alias": "Website",
"daysRemaining": 7,
"expirationDate": "2026-10-08T23:59:59.000Z",
"issuer": "R11",
"fingerprint": null,
"previous": null,
"timestamp": "Oct 01 2026, 10:00:03 UTC"
}
```
## Troubleshooting
**The certificate works in my browser but Hyperping reports an incomplete chain**
Browsers fetch or cache missing intermediates; most other clients don't. Configure your server to send the full chain (on nginx, use the `fullchain.pem` file rather than `cert.pem`).
**Untrusted root on an internal service**
Services behind a private CA are reported as untrusted, because browsers and API clients without your CA installed would refuse them. The problem existing when the monitor is created doesn't send an alert; only a change does.
**The certificate didn't update after renewal**
Click **Recheck**. If the old certificate is still shown, your server, load balancer or CDN still serves it: reload the web server, or check that the CDN has the new certificate. DNS changes can also take time to reach every resolver.
**An HTTPS monitor shows no certificate**
The check couldn't complete a TLS handshake (host down, port closed, firewall, or a server that only accepts a specific client). The last certificate read stays on the monitor until a check succeeds again.
## Next steps
[
Domain expiry monitoring→
Get warned before the domain registration itself lapses.
](https://hyperping.com/docs/monitoring/domain-expiry)[
DNS monitoring→
Catch hijacked or broken records before your users do.
](https://hyperping.com/docs/monitoring/dns)[
Ping and port monitoring→
Monitor hosts and services that don't speak HTTP.
](https://hyperping.com/docs/monitoring/ping-port)[
Escalation policies→
Route alerts in order, with delays, until resolved.
](https://hyperping.com/docs/monitoring/escalation-policies)
[← Datacenter regions](https://hyperping.com/docs/monitoring/datacenter-regions)[Domain expiry monitoring →](https://hyperping.com/docs/monitoring/domain-expiry)
[](https://x.com/hyperping)[](https://www.linkedin.com/company/hyperping)
© 2026 Hyperping
---
Source: https://hyperping.com/docs/status-page
# Status page Documentation
### Table of contents
- [Create a status page](https://hyperping.com/docs/status-page/create-status-page)
- [Add services](https://hyperping.com/docs/status-page/add-services)
- [Components](https://hyperping.com/docs/status-page/components)
- [Sections](https://hyperping.com/docs/status-page/sections)
- [Incident calendar](https://hyperping.com/docs/status-page/incident-calendar)
- [Publish and manage incidents](https://hyperping.com/docs/status-page/incidents)
- [Public post-mortems](https://hyperping.com/docs/status-page/post-mortems)
- [Custom domain](https://hyperping.com/docs/status-page/custom-domain)
- [Subscribers](https://hyperping.com/docs/status-page/subscribers)
- [Private status pages](https://hyperping.com/docs/status-page/private-status-pages)
- [Status page SSO](https://hyperping.com/docs/status-page/sso)
- [White labeling](https://hyperping.com/docs/status-page/white-labeling)
- [Multi-language status pages](https://hyperping.com/docs/status-page/languages)
- [SMS Notifications (Twilio)](https://hyperping.com/docs/status-page/sms-notifications)
- [RSS and Atom feeds](https://hyperping.com/docs/status-page/rss-atom-feeds)
- [Status Page JSON](https://hyperping.com/docs/status-page/status-page-json)
- [Status page public API](https://hyperping.com/docs/status-page/public-api)
- [Footer badge](https://hyperping.com/docs/status-page/footer-badge)
- [SEO and analytics](https://hyperping.com/docs/status-page/seo-analytics)
- [How we calculate uptime](https://hyperping.com/docs/status-page/uptime-calculation)
- [Go-live checklist](https://hyperping.com/docs/status-page/go-live-checklist)
- [Migrate to version 2](https://hyperping.com/docs/status-page/migrate-to-v2)
- [Import from Statuspage.io](https://hyperping.com/docs/status-page/import-from-statuspage)
[](https://x.com/hyperping)[](https://www.linkedin.com/company/hyperping)
© 2026 Hyperping
---
Source: https://hyperping.com/docs/status-page/add-services
# Add services to your status page
Show the status of your services on a dedicated page and inform your users about incidents in real time.
Services use our built-in monitoring to show their real-time status inside your status page. When our systems detect an outage, your service's status will automatically be updated on your status page.
> **Before you start**
>
> Services use your monitors to show the real-time status, so make sure that you have already [created one](https://hyperping.com/docs/monitoring/getting-started). Services live inside [sections](https://hyperping.com/docs/status-page/sections). [Healthchecks](https://hyperping.com/docs/monitoring/healthchecks) can be added too, so a scheduled job shows up as a service with its uptime.
Adding services from the Sections tab of the builder
### Add a service
Services are added within [Sections](https://hyperping.com/docs/status-page/sections). You can add as many services as you'd like.
1. Open the Sections tab
Go to your status page settings and head to the **Sections** tab.
2. Open a section
Open the section you want the service to appear in.
3. Pick a monitor
Hover on any service in the **Available** list to add it. It will be added and shown in the preview.
### Show service's metrics
Each monitored service comes with 2 optional metrics that can be displayed:
- **Uptime**: shows a graph of historical data of the past 90 days of the service's uptime, in percentage of availability.
- **Response time**: shows a graph of the response time from our monitoring over the past 24 hours. It helps give a sense of the current responsiveness/latency of your applications.
To enable these options, click on the **Gear icon** over the selected service.
> **Where does the uptime number come from?**
>
> See [How we calculate uptime](https://hyperping.com/docs/status-page/uptime-calculation) for the exact formula behind the graphs your visitors see.
### Change a service's name
Monitor names can be different than what you'd like your users to see. Upon adding a service and clicking on the **Gear icon**, you can change your service's name.
### Change services' order
To change your services' order, hover a service and click on either the top or down arrow to change its position within the section.
### Components or dummy monitors
Components are dummy monitors added to status pages that can be manually updated by selecting them when creating an [incident](https://hyperping.com/docs/status-page/incidents) or [maintenance window](https://hyperping.com/docs/maintenance/create-maintenance).
## Next steps
[
Sections→
Group your services into sections and logical groups.
](https://hyperping.com/docs/status-page/sections)[
Publish incidents→
Report incidents on your page and notify subscribers.
](https://hyperping.com/docs/status-page/incidents)[
How we calculate uptime→
The formula behind the uptime numbers your visitors see.
](https://hyperping.com/docs/status-page/uptime-calculation)[
Go-live checklist→
Everything to verify before you announce your status page.
](https://hyperping.com/docs/status-page/go-live-checklist)
[← Create a status page](https://hyperping.com/docs/status-page/create-status-page)[Components →](https://hyperping.com/docs/status-page/components)
[](https://x.com/hyperping)[](https://www.linkedin.com/company/hyperping)
© 2026 Hyperping
---
Source: https://hyperping.com/docs/status-page/components
# Components
Put things on your status page that Hyperping does not monitor, and set their status by hand.
Most services on a status page are backed by a monitor: Hyperping checks them and the status updates itself. A component is the other kind. It appears on your page like any other service, but nothing checks it, so its status only changes when you publish an incident or a maintenance window that affects it.
Components exist for everything you are accountable for but cannot ping:
- A third-party service your product depends on, like a payment provider or an email sender
- Something with no public endpoint: a data pipeline, a batch job, an internal queue
- A physical or human dependency, like an office network or a support desk
- A service you want listed on the page before its monitor exists
> **Component or monitored service?**
>
> If Hyperping can reach it over HTTP, TCP, ping, or a browser check, make it a [monitor](https://hyperping.com/docs/monitoring/create-monitor) and [add it as a service](https://hyperping.com/docs/status-page/add-services). You get automatic status, uptime history, and response times. Reach for a component only when there is nothing to check.
## Create a component
1. Open Components
Go to [Components](https://app.hyperping.io/components) in the sidebar, under Status Pages.
2. Create it
Hit **New component** and give it the name your visitors should see, for example "Payment provider" or "Email delivery".
3. Add it to a status page
Open your status page and add the component the same way you [add a service](https://hyperping.com/docs/status-page/add-services). One component can sit on several status pages, and the Components list shows which pages each one appears on.
## Changing a component's status
A component sits at operational until you say otherwise. To change that, publish an [incident](https://hyperping.com/docs/status-page/incidents) or a [maintenance window](https://hyperping.com/docs/maintenance/create-maintenance) and select the component as an affected service. Its status on the page follows the incident, and returns to operational when you resolve it.
That is the whole model: there is no separate status dropdown to forget about, and no way for a component to be stuck red with no incident explaining why.
## What components do not have
Because nothing checks them, components carry no uptime percentage, no response time chart, and no 90-day history bar. On the page they show their current status and the incidents that touched them, nothing more. A page mixing monitored services and components will show uptime for some rows and not others, which is expected.
## Troubleshooting
**My component shows no uptime bar**
Working as intended. Uptime is computed from monitor checks, and a component has none. If you want a history bar, the service has to be backed by a monitor.
**The component is stuck in a degraded state**
An incident affecting it is still open. Resolve the incident, or remove the component from its affected services, and the status returns to operational.
**I deleted a component that was on a live page**
Deleting removes it from every status page it appeared on, and there is no undo. Recreate it and add it back to each page. Rename instead of deleting when you only need to change the wording, since renaming keeps the component on every page it is already on.
## Next steps
[
Add services→
Put monitors and components on the page and group them.
](https://hyperping.com/docs/status-page/add-services)[
Publish incidents→
Select affected services and drive their status.
](https://hyperping.com/docs/status-page/incidents)[
Maintenance windows→
Schedule planned work on a component.
](https://hyperping.com/docs/maintenance/create-maintenance)[
Sections→
Organize services and components into groups.
](https://hyperping.com/docs/status-page/sections)
[← Add services](https://hyperping.com/docs/status-page/add-services)[Sections →](https://hyperping.com/docs/status-page/sections)
[](https://x.com/hyperping)[](https://www.linkedin.com/company/hyperping)
© 2026 Hyperping
---
Source: https://hyperping.com/docs/status-page/create-status-page
# How to create a status page
Build your status page with the status page builder. Every setting is covered below, from domains and access control to branding.
> **Before you start**
>
> Services on a status page are powered by monitors, so make sure you have already [created a monitor](https://hyperping.com/docs/monitoring/getting-started).
The editor consists of 3 sections (tabs):
1. [Settings](https://hyperping.com/docs/status-page/create-status-page#1-settings): edit the settings, such as your status page's name or custom domain.
2. [Sections](https://hyperping.com/docs/status-page/add-services): add services from your monitors, show uptime and/or response time graphs.
3. [Subscribers](https://hyperping.com/docs/status-page/subscribers): manage your subscribers.
The status page builder
## 1\. Settings
### Custom domain
You can use your own subdomain to host your status page.
Create a CNAME record with a **status** value, pointing to **cname.hyperping.io**.
> **Need the full domain walkthrough?**
>
> DNS propagation can take up to 24 hours. The [custom domain guide](https://hyperping.com/docs/status-page/custom-domain) covers apex domains, subdomains, and SSL certificates.
### Hyperping-hosted slug
We offer the ability to quickly host your status page on our own **YOUR\_NAME.hyperping.app** domain. While DNS propagation of a custom domain can take up to 24 hours, this instantly gives you a URL you can share with your team or use for a demo, for example.
### Name
The name to be used in the status page's header link: "**Go to Acme**".
### Website
The website the link in the status page will head to.
### Status page description
Display a small informative text explaining what this page is about. It will be shown underneath the top-level status.
### Subscriber notifications
Select which channels your status page visitors can subscribe to whenever you publish an incident.
You can enable up to 4 channels:
- **Email**: subscribers will need to confirm their subscription. You can also add subscribers manually from the builder's **Subscribers** tab.
- **Slack**: subscribers can easily connect any Slack channel.
- **Microsoft Teams**: subscribers can receive notifications directly in their Teams channels.
- **SMS**: you will need to connect your [own Twilio account](https://hyperping.com/docs/status-page/sms-notifications).
See [Subscribers](https://hyperping.com/docs/status-page/subscribers) for how each channel works.
### Subscribe to specific updates
Subscribers can choose which services they receive notifications about.
Subscribers can pick the services they want updates for
### Password protection
Protect your status page under a password that you can share with others. You can edit it at any time.
The sign-in screen on a password protected status page
### SAML SSO
Single sign-on for status page visitors requires Business and a separately billed SSO connection. Pro includes private pages protected by passwords or email access codes.
Protect your status page with your identity provider, such as Okta, Microsoft Entra ID, Google Workspace or Auth0. Create the connection under **Status Pages → SSO Connections**, then turn on **SAML SSO** here and pick it in the **SSO Connection** dropdown. The toggle works with SAML and OpenID Connect connections alike. [Status page SSO](https://hyperping.com/docs/status-page/sso) walks through each provider.
### Google SSO
Protect your status page under Google SSO. Add a domain under **Allowed emails domains** to let email addresses with specific domains log in to this status page.
> **Plan availability**
>
> Google SSO is accessible starting Business plans.
> **Building a private status page?**
>
> Password protection, Google SSO, and SSO connections are covered in depth in [Private status pages](https://hyperping.com/docs/status-page/private-status-pages).
### Hide from search engines
A toggle whether you'd like to hide your page from being indexed and found by search engines. See [SEO and analytics](https://hyperping.com/docs/status-page/seo-analytics) for what it does and does not protect.
### Google Analytics
Add your own Google Analytics tag. Both GA4 (`G-XXXXXXXXXX`) and Universal Analytics (`UA-XXXXXX-YY`) IDs are accepted. See [SEO and analytics](https://hyperping.com/docs/status-page/seo-analytics).
### Multi-language status pages
Serve your status page in English, French, German, Dutch, Polish, Russian, or Swedish. Pick a default language on any plan, and add more from the Pro plan.
Every incident and maintenance update then gets one text input per language. See the [multi-language guide](https://hyperping.com/docs/status-page/languages) for how visitors switch and how the feeds and API expose each language.
### Auto refresh and TV mode
Turn this on and your status page refreshes itself every 60 seconds, and gains a control to expand to fullscreen. It is built for the screen nobody touches: a wallboard in the support room, a monitor above the ops desk, a spare TV in the office.
Open the page on that display, switch it to fullscreen, and leave it. Nobody has to reload anything, and an incident you publish shows up there within the minute. Pair it with a [private page](https://hyperping.com/docs/status-page/private-status-pages) if the wallboard should carry internal services your customers do not see.
> **Plan availability**
>
> Auto refresh and TV mode require the Pro plan. Additional languages are included from Pro.
## Customisation
We offer customisation for your status page to match it best with your branding.
The Appearance panel: font, theme, accent color, favicon, and logo, all in one place.
### Font
Choose between a set of popular Google Fonts that we already include.
### Interface theme
Choose between user's system preferences, or force only light or dark modes.
### Hide "Powered by" footer
White label your status page by hiding our "Powered by" logo in the footer.
> **Plan availability**
>
> Hiding the "Powered by" footer is accessible starting Business plans.
> **Going for a fully branded page?**
>
> The [white labeling guide](https://hyperping.com/docs/status-page/white-labeling) combines the custom domain, the hidden footer, and subscriber emails sent from your own domain.
### Banner header
Choose between a compact or large top-level status header.
### New design
Opt in to the refreshed status page look: neutral grays, softer typography, and a unified status icon set.
Service cards, incident cards, and the status banner share the same hairline borders and rounded corners, and the four status icons (operational, incident, outage, maintenance) come from a single set so the page reads consistently. The new design has its own light and dark palettes.
### Incident calendar
Show a monthly calendar of incidents and maintenances at the bottom of the page. Learn more in the [Incident calendar](https://hyperping.com/docs/status-page/incident-calendar) docs.
### Accent color
Choose your accent color.
It will change the colors of the check icons, uptime bars, as well as the "Get Updates" button upon hovering.
### Favicon
Customise your status page with your own favicon.
### Company logo
Make your company logo appear in the top-left of the status page's header.
### Logo for dark mode
Optionally upload a second logo to be shown when the page is in dark mode, so a dark logo stays visible. If you only set one logo, it is used in both themes.
### Logo height
Adjust the rendered height of your logo, from 20 to 64 pixels. The default is 32 pixels and the width scales automatically.
## 2\. Add services
Once you have configured your status page, add [sections and services](https://hyperping.com/docs/status-page/add-services) to show the systems your users care about.
## Next steps
[
Add services→
Pick monitors to display, with uptime and response time graphs.
](https://hyperping.com/docs/status-page/add-services)[
Custom domain→
Serve your page from your own domain with automatic SSL.
](https://hyperping.com/docs/status-page/custom-domain)[
How we calculate uptime→
The formula behind the uptime numbers your visitors see.
](https://hyperping.com/docs/status-page/uptime-calculation)[
Go-live checklist→
Everything to verify before you announce your status page.
](https://hyperping.com/docs/status-page/go-live-checklist)
[Add services →](https://hyperping.com/docs/status-page/add-services)
[](https://x.com/hyperping)[](https://www.linkedin.com/company/hyperping)
© 2026 Hyperping
---
Source: https://hyperping.com/docs/status-page/custom-domain
# How to setup a custom domain for your status page
Host your status page under your own custom domain.
The Domain panel: add a custom domain, or use your Hyperping-hosted slug
## Custom domain
Host your status page under any custom domain: either your apex domain (acme.com) or any subdomain (status.acme.com, uptime.acme.com, internal.status.acme.com, etc.).
1. Open Status Pages
Go to [Status Pages](https://app.hyperping.io/v2/statuspage) in your Hyperping dashboard.
2. Pick a status page
Pick the status page you want to add a domain to.
3. Enter your custom domain
Enter your custom domain in the "Custom domain" section.
4. Publish
Hit Publish.
5. Configure your DNS records
Add the record shown in the panel to your DNS zone. The exact name and value are displayed with a copy button next to each one.
### DNS records
| Domain | Type | Name | Value |
| --- | --- | --- | --- |
| Subdomain (status.acme.com) | CNAME | status | cname.hyperping.io |
| Apex domain (acme.com) | A | @ | 216.150.1.1 |
The **Name** is relative to your DNS zone, so a page on internal.status.acme.com uses _internal.status_, not the full hostname. Most DNS providers add the rest for you.
Once the record is saved, leave the Domain panel open. It rechecks your DNS on its own, and you can force a check with the **Check DNS** button. When everything resolves, the panel shows **Connected · SSL certificate active** and we email you that the page is live.
### Domain verification (TXT record)
A third record sometimes appears in the panel: a TXT record named **\_vercel**. It shows up when your domain is already in use on the infrastructure that serves status pages, most often because your main website is hosted on Vercel. In that case we need proof that the domain is yours before we can serve a page on it.
The record is temporary and does not route any traffic. It only proves ownership. A few things to know:
- It always goes on your apex domain (\_vercel.acme.com), even when your status page lives on a subdomain.
- Its value is unique to your domain. Copy it from the panel rather than from another guide.
- Once the panel flips to **Connected**, the record has done its job. Leaving it in place is harmless and saves a round trip if you ever re-add the domain.
> **Add the TXT record, don't replace the ones you have**
>
> TXT records stack on the same name. Add this one alongside your SPF, DKIM, and other verification records instead of overwriting them. Replacing them is the single most common way this step goes wrong, and it breaks your email deliverability at the same time.
### SSL certificates (HTTPS)
All status pages are served using HTTPS only, and HTTP requests are redirected to HTTPS. We issue and renew the certificate for you (Let's Encrypt), so there is nothing to upload, and renewal happens automatically 30 days before expiry.
The certificate is only issued once your domain actually resolves to us, which means the order matters: DNS first, certificate second. Between the two, a browser hitting your domain can show a certificate warning or a "site not found" error. That is expected and clears on its own, usually within a minute of the DNS check passing.
Two DNS settings can block the certificate from ever being issued:
- **A Cloudflare proxied record** (orange cloud). Cloudflare answers for the hostname instead of us, so the validation never reaches our servers. Switch the record to **DNS only** (grey cloud).
- **A restrictive CAA record** on your domain. If you use CAA records, they must allow _letsencrypt.org_ to issue certificates, otherwise the request is refused.
> **Want the page fully on your brand?**
>
> A custom domain is the first step of white labeling. See the [white labeling guide](https://hyperping.com/docs/status-page/white-labeling) for hiding the "Powered by" footer and sending subscriber emails from your own domain.
## Hyperping-hosted domain
Each status page can have a custom Hyperping-hosted domain (yourdomain.hyperping.app) that is instantly available. This is perfect for testing your status page or in case obtaining a custom domain requires more time.
Head to your status page settings, edit the field under the "Hyperping-hosted slug" section, then hit "Publish".
All Hyperping-hosted status pages are served using HTTPS only.
## Troubleshooting
**My custom domain is not live yet**
DNS propagation can take up to 24 hours after you create the record, though it is usually a matter of minutes. In the meantime, your Hyperping-hosted domain (yourdomain.hyperping.app) is instantly available, so you already have a working URL to share.
**My domain is on Cloudflare and nothing works**
Open the record in Cloudflare and set it to **DNS only** (grey cloud). While the orange cloud is on, Cloudflare answers for your hostname with its own IP addresses, so our DNS check fails and the SSL certificate cannot be issued. The panel flags this for you when it detects Cloudflare's edge.
**The panel says my domain points somewhere else**
Something already answers for that hostname: a previous status page provider, a parking page, or a typo in the target. Adding a second record does not help, and if the existing record is the wrong type (an A record where we need a CNAME), your provider will reject the new one. Edit the existing record instead of creating another.
**I added the TXT record and it still says pending**
Check that you added it rather than replaced your existing TXT records, that the name is **\_vercel** on your apex domain, and that the value matches the panel exactly (no quotes, no trailing spaces). Then hit **Check DNS**. If your provider shows the record but we still do not see it, give it a few minutes: some registrars only publish TXT changes on their own refresh cycle.
## Next steps
[
White labeling→
Hide the "Powered by" footer and send emails from your domain.
](https://hyperping.com/docs/status-page/white-labeling)[
Private status pages→
Password, SSO, and email access codes for internal pages.
](https://hyperping.com/docs/status-page/private-status-pages)[
Go-live checklist→
Everything to verify before you announce your status page.
](https://hyperping.com/docs/status-page/go-live-checklist)[
Create a status page→
Every setting of the status page builder, explained.
](https://hyperping.com/docs/status-page/create-status-page)
[← Sections](https://hyperping.com/docs/status-page/sections)[Subscribers →](https://hyperping.com/docs/status-page/subscribers)
[](https://x.com/hyperping)[](https://www.linkedin.com/company/hyperping)
© 2026 Hyperping
---
Source: https://hyperping.com/docs/status-page/footer-badge
# Footer badge
Display a badge showing the real-time status of your status page services. You can create one by using our badge builder here: [https://hyperping.com/badge-builder](https://hyperping.com/badge-builder).
The badge builder generates a code snippet from your settings
## Fine tune your settings
Choose to display the uptime, change the wording and link your status page. A code snippet will automatically be updated as you edit your settings.
## Link it to your status page
In order for it to automatically update your badge's status and uptime, you will need to plug in your status page's URL. If you haven't created a status page yet, you can follow [this guide](https://hyperping.com/docs/status-page/create-status-page).
The badge uses the [endpoint of your status page](https://hyperping.com/docs/status-page/status-page-json) to retrieve real-time data about your uptime and status indicator.
## How to integrate it
1. Add the badge element
Add an element that contains a "hyperping-badge" id, for example in your footer, next to other links.
```html
```
2. Load the badge script
Add the Hyperping badge's script to your website.
```html
```
3. Initialize it with your settings
Paste the generated code that includes your badge's settings.
```html
```
Try it out here: [https://hyperping.com/badge-builder](https://hyperping.com/badge-builder).
## Next steps
[
Status page JSON→
The public endpoint the badge reads its status and uptime from.
](https://hyperping.com/docs/status-page/status-page-json)[
How we calculate uptime→
The math behind the uptime number your badge can display.
](https://hyperping.com/docs/status-page/uptime-calculation)[
Create a status page→
Build the status page your badge links to.
](https://hyperping.com/docs/status-page/create-status-page)[
Go-live checklist→
Everything to verify before you announce your status page.
](https://hyperping.com/docs/status-page/go-live-checklist)
[← Status page public API](https://hyperping.com/docs/status-page/public-api)[SEO and analytics →](https://hyperping.com/docs/status-page/seo-analytics)
[](https://x.com/hyperping)[](https://www.linkedin.com/company/hyperping)
© 2026 Hyperping
---
Source: https://hyperping.com/docs/status-page/go-live-checklist
# Go-live checklist
Your status page is built. Run through this checklist before you share the URL, so the page your users discover is complete, branded, and the only source of truth from day one.
## 1\. Get services and sections ready
The page is only useful if it shows the services your users actually care about.
1. Add your services
Services pull their real-time status from your monitors. [Add them](https://hyperping.com/docs/status-page/add-services) from the Sections tab, and use the Gear icon to rename any service whose monitor name would confuse outsiders.
2. Organize them into sections
Group services into [sections](https://hyperping.com/docs/status-page/sections), and into groups within sections, by product area, region, or team. Reorder them so the most important services come first.
3. Choose the metrics to display
Each service can show an uptime graph of the past 90 days and a response time graph of the past 24 hours. Toggle them from the Gear icon on the selected service.
## 2\. Put it on your own domain
A status page on your own domain is easier to find and easier to trust. Follow the [custom domain guide](https://hyperping.com/docs/status-page/custom-domain).
1. Configure DNS
For a subdomain like status.acme.com, create a CNAME record pointing to cname.hyperping.io. For an apex domain, create an A record pointing to 216.150.1.1.
2. Publish and verify HTTPS
Enter the domain in your status page settings and hit Publish. Every status page is served over HTTPS only, with an automatic SSL certificate renewed 30 days before expiry.
3. Keep the hyperping.app URL as a fallback
DNS propagation can take up to 24 hours. Your Hyperping-hosted slug (yourname.hyperping.app) is instantly available, so you can test and demo while you wait.
## 3\. Brand it and white label it
Make the page unmistakably yours before anyone sees it. The [white labeling guide](https://hyperping.com/docs/status-page/white-labeling) covers the full setup.
1. Apply your visual branding
Set your company logo (with an optional dark mode logo), favicon, accent color, font, and theme from the [status page builder](https://hyperping.com/docs/status-page/create-status-page). Visual branding is available on all plans.
2. Remove Hyperping branding
On the Business plan, hide the "Powered by Hyperping" footer and send subscriber emails from your own domain, so every touchpoint carries your brand.
3. Set indexing and analytics
Decide whether search engines should find the page with the "Hide from search engines" toggle, and add your Google Analytics tag if you want traffic data. Both live in the builder's Settings tab.
## 4\. Open subscriber notifications
Subscribers hear about incidents from you, not from Twitter. Set the channels up in the [Subscribers tab](https://hyperping.com/docs/status-page/subscribers).
1. Pick the channels
Offer up to 4 channels: email, Slack, Microsoft Teams, and SMS. SMS requires connecting [your own Twilio account](https://hyperping.com/docs/status-page/sms-notifications), so only enable it if you use Twilio.
2. Bring your existing subscribers over
Manually add email subscribers from your previous tool, up to 500 addresses at once, or use the Subscribers API. Slack, Teams and SMS subscribers must subscribe through their own channels, so invite them to re-subscribe on the new page.
## 5\. Decide who can see it
Leave the page public, or restrict it before the URL starts circulating.
1. Public page
Nothing to do. Anyone with the URL can view it, which is what most customer-facing status pages want.
2. Private page
Go to Settings → Page Access and protect it with a password, Google SSO, email access codes, or single sign-on through your identity provider (SAML or OpenID Connect). The [private status pages guide](https://hyperping.com/docs/status-page/private-status-pages) compares the four options.
## 6\. Announce it and switch over
The final step is making the new page the only one your users ever see.
1. Import your incident history
Coming from StatusPage.io? [Import your historical incidents and maintenances](https://hyperping.com/docs/status-page/import-from-statuspage) first, so the new page launches with your track record instead of an empty history.
2. Communicate the new URL and update your links
Share the new address with your users, then update every link that pointed to the old page: your website, your emails, and your docs. Add the [footer badge](https://hyperping.com/docs/status-page/footer-badge) to your site so real-time status is one click away.
3. Turn off the old status page
Once the new page is live and linked, shut the old one down. Running two pages means posting every update twice, and the stale one will eventually contradict the real one.
> **Go-live recap, in 6 points**
>
> - Services added, renamed for outsiders, and grouped into sections.
> - Custom domain live with automatic HTTPS.
> - Branding applied, Hyperping branding removed if white labeled.
> - Subscriber channels open and existing subscribers imported.
> - Access set: public, or protected the way you want.
> - New URL announced, links updated, old page turned off.
## Next steps
[
Publish and manage incidents→
Report incidents, post updates, and notify subscribers at every step.
](https://hyperping.com/docs/status-page/incidents)[
How we calculate uptime→
The math behind the uptime bars your visitors now see.
](https://hyperping.com/docs/status-page/uptime-calculation)[
Incident calendar→
Give visitors a month-at-a-glance view of past incidents and maintenances.
](https://hyperping.com/docs/status-page/incident-calendar)[
Import from StatusPage.io→
Migrate your historical incidents and maintenances in a few clicks.
](https://hyperping.com/docs/status-page/import-from-statuspage)
[← How we calculate uptime](https://hyperping.com/docs/status-page/uptime-calculation)[Publish incidents →](https://hyperping.com/docs/status-page/incidents)
[](https://x.com/hyperping)[](https://www.linkedin.com/company/hyperping)
© 2026 Hyperping
---
Source: https://hyperping.com/docs/status-page/import-from-statuspage
# Import from StatusPage.io
Learn how to migrate your incidents and maintenances from StatusPage.io to Hyperping.
Our import tool allows you to easily migrate your historical incidents and scheduled maintenances from StatusPage.io to your Hyperping status page.
> **Moving your whole setup off StatusPage.io?**
>
> This page covers the importer for your historical incidents and maintenances. For the complete move (concept mapping, monitors, domain, branding, and subscribers), follow the [Migrate from Statuspage.io guide](https://hyperping.com/docs/migrate/from-statuspage).
The StatusPage.io import tool
## How it works
The import process is straightforward and gives you full control over what gets migrated:
1. Export your data from StatusPage.io
Get your incidents and maintenances as JSON files.
2. Upload to Hyperping
Use our import tool at [app.hyperping.io/statuspage/import](https://app.hyperping.io/statuspage/import).
3. Match components
Map your StatusPage.io components to Hyperping monitors/components.
4. Choose destination
Select which status page each incident/maintenance will appear in.
5. Import
Review and import your selected items.
Matching components and choosing destinations before importing
## Step 1: Export data from StatusPage.io
To get your data from StatusPage.io, you'll need to access their API endpoints directly. Add the following paths to your StatusPage.io URL:
### For incidents:
Add `/api/v2/incidents.json` to your StatusPage.io URL
**Example:** `https://yourcompany.statuspage.io/api/v2/incidents.json`
### For scheduled maintenances:
Add `/api/v2/scheduled-maintenances.json` to your StatusPage.io URL
**Example:** `https://yourcompany.statuspage.io/api/v2/scheduled-maintenances.json`
Save these JSON files to your computer: you'll upload them in the next step.
## Step 2: Import to Hyperping
Navigate to [app.hyperping.io/statuspage/import](https://app.hyperping.io/statuspage/import) and upload your JSON file(s).
## Step 3: Match components
During the import process, you'll be able to match StatusPage.io components to your existing Hyperping monitors or components. This ensures that imported incidents appear on the correct services in your status page.
## Step 4: Choose status pages
If you have multiple status pages in Hyperping, you can choose which status page each incident or maintenance should appear on. This gives you flexibility in organizing your historical data.
## Import recommendations
- **Start small**: We recommend trying a few incidents/maintenances first to test the process
- **Batch size**: The system processes imports in batches of 15 items at a time from the frontend
- **Large imports**: For large datasets, consider splitting your JSON files into chunks of a few hundred incidents maximum
- **Review before importing**: Use the preview feature to review what will be imported before finalizing
## What gets imported
The import tool will migrate:
- Incident details (title, description, status, timestamps)
- Maintenance windows (title, description, scheduled times)
- Component associations
- Status updates and timeline
## Need help?
If you need assistance with the import process or encounter any issues, don't hesitate to reach out to us via the chat or email at hello@hyperping.io. We're here to help make your migration as smooth as possible.
## Next steps
[
Migrate from Statuspage.io→
The complete migration guide, from concept mapping to going live.
](https://hyperping.com/docs/migrate/from-statuspage)[
Publish incidents→
Report incidents, post updates, and notify subscribers at every step.
](https://hyperping.com/docs/status-page/incidents)[
Incident calendar→
Give visitors a month-at-a-glance view of past incidents and maintenances.
](https://hyperping.com/docs/status-page/incident-calendar)[
Go-live checklist→
Everything to verify before you announce your status page.
](https://hyperping.com/docs/status-page/go-live-checklist)
[← Migrate to version 2](https://hyperping.com/docs/status-page/migrate-to-v2)
[](https://x.com/hyperping)[](https://www.linkedin.com/company/hyperping)
© 2026 Hyperping
---
Source: https://hyperping.com/docs/status-page/incident-calendar
# Incident calendar
Show a monthly calendar of incidents and maintenances at the bottom of your status page.
Incident calendar on a status page, with an incident marked on July 7
The calendar gives visitors a month-at-a-glance view of your reliability. Days with incidents or maintenances are circled, and hovering a day lists what happened with links to the full incident details. It complements the incident history section, which stays chronological.
- Show customers evaluating your service that incidents are rare, on a single screen.
- Let visitors check whether a specific date had an incident without scrolling through history.
- Display upcoming maintenance windows on their scheduled date.
## Enable the calendar
1. Open your status page
Navigate to **Status Pages** and select your status page.
2. Open the Appearance settings
In the **Settings** tab, open **Appearance**.
3. Turn on Incident calendar
Enable the **Incident calendar** option.
4. Publish
Click **Publish**.
The calendar is off by default and is configured per status page.
## What visitors see
The calendar renders at the bottom of the page, after the incident history. Weeks run Monday to Sunday, and the arrows next to the month name navigate to past or future months.
A day with at least one event shows its number in a colored circle. The color reflects the most severe event of that day:
| Color | Event type |
| --- | --- |
| Red | Outage |
| Amber | Incident |
| Blue | Maintenance |
Hovering a marked day opens a tooltip with the date and the list of events, each linking to its incident page. Scheduled maintenances appear on their planned date, so visitors can also see what is coming up.
Weekday and month names follow the language of the status page. On [multi-language status pages](https://hyperping.com/docs/status-page/create-status-page), the calendar is localized like the rest of the page.
> **Where do these events come from?**
>
> Incidents are published from your dashboard or opened automatically by monitoring: see [Publish and manage incidents](https://hyperping.com/docs/status-page/incidents). Planned work comes from [maintenance windows](https://hyperping.com/docs/maintenance/create-maintenance), shown on their scheduled date.
## Next steps
[
Publish incidents→
Report incidents, post updates, and notify subscribers.
](https://hyperping.com/docs/status-page/incidents)[
Maintenance windows→
Schedule planned work so visitors see it coming.
](https://hyperping.com/docs/maintenance/create-maintenance)[
How we calculate uptime→
The formula behind the uptime numbers your visitors see.
](https://hyperping.com/docs/status-page/uptime-calculation)[
Create a status page→
Every setting of the status page builder, explained.
](https://hyperping.com/docs/status-page/create-status-page)
[← Sections](https://hyperping.com/docs/status-page/sections)[Custom domain →](https://hyperping.com/docs/status-page/custom-domain)
[](https://x.com/hyperping)[](https://www.linkedin.com/company/hyperping)
© 2026 Hyperping
---
Source: https://hyperping.com/docs/status-page/incidents
# Publish and manage incidents
Report incidents on your status page, post updates as you work through them, and notify subscribers at every step.
When something breaks, your status page is where customers look first. Hyperping lets you publish an incident, attach it to the affected services, and keep the timeline updated until resolution. Subscribers are notified on the channel they picked, so your support inbox stays quieter during an outage.
- Announce a degraded third-party dependency that your monitoring may not catch.
- Keep customers informed during an outage without leaving your incident workflow.
- Build a public history that shows how you communicate when things go wrong.
> **Plan availability**
>
> Publishing incidents and maintenances to a status page is included in paid plans. See the [pricing page](https://hyperping.com/pricing) for details.
## Manual incidents and automated outage detection
Incidents appear on your status page in two ways:
- Hyperping monitors your services and automatically creates incidents when outages are detected. The affected service is marked as down on your status page without any manual work.
- You can also declare incidents yourself from the dashboard, with a description and immediate team notification. Use manual incidents for problems your monitoring cannot see, such as a degraded feature that still returns a 200, or an upstream provider issue.
A manual report has a criticality, either **incident** or **outage**, which reflects how severe the event is. The [incident calendar](https://hyperping.com/docs/status-page/incident-calendar) shows outages in red and incidents in amber.
The Updates view lists every incident you published, with its status and update count
> **Announcing planned work rather than an incident?**
>
> Schedule a [maintenance window](https://hyperping.com/docs/maintenance/create-maintenance) instead. It appears on your status page on its scheduled date, so visitors see it coming.
## Create an incident from the dashboard
1. Create a new incident
Open your project dashboard and create a new incident.
2. Write a clear title
On multi-language status pages, you can provide the title in each language of the page.
3. Choose the type
Either outage or incident, reflecting how severe the event is.
4. Select the affected services
This determines which components show as impacted, and which subscribers get notified.
5. Choose the status pages
If you run several status pages, choose which pages the incident is reported on.
6. Publish the first update
Write the first update, usually an investigating message, and publish.
The composer: title, lifecycle status, criticality, and the status pages to publish on
## Post updates through the incident lifecycle
An incident is a timeline of updates. Each update has a status that tells visitors where you are in the resolution process:
| Status | When to use it |
| --- | --- |
| Investigating | You are aware of the problem and looking into the cause. |
| Identified | You found the cause and are working on a fix. |
| Update | Intermediate progress that does not change the status. |
| Monitoring | A fix is deployed and you are watching for recurrence. |
| Resolved | The incident is over. This closes the timeline. |
You do not have to go through every status. A short incident can jump from investigating straight to resolved. Use rich text formatting in the update body to keep longer updates readable.
An incident timeline: each update is stamped with its status and time
## Explain the incident with a post-mortem
Once an incident is resolved, you can publish a post-mortem on it: what happened, why, and what you changed. It appears at the top of the incident on your status page, as a **Postmortem - Read details** entry in the history and in full on the incident page. You can keep it as a draft while your team reviews it, or start from the internal post-mortem of the alerting incident. See [Public post-mortems](https://hyperping.com/docs/status-page/post-mortems).
## How subscribers get notified
Visitors can subscribe to your status page through up to four channels: email, Slack, Microsoft Teams, and SMS. Every update you publish notifies subscribers on the channel they chose. See [Subscribers](https://hyperping.com/docs/status-page/subscribers) for how each channel works and how to enable them.
Notifications are scoped by the services you select on the incident. Subscribers who follow specific services only hear about incidents affecting those services.
SMS notifications to subscribers require connecting your own Twilio account. Follow the [SMS notifications guide](https://hyperping.com/docs/status-page/sms-notifications) to set it up.
## Acknowledge and escalate monitor-detected outages
When a monitor detects an outage, your team is alerted through your configured [notification channels](https://hyperping.com/docs/projects/notification-channels). Acknowledging the outage takes ownership of it and stops repeat alerts. The steps of its escalation policy still fire on schedule until the outage is resolved, so the next level is paged, on the channels defined for it, if the problem lasts.
With the [Slack integration](https://hyperping.com/docs/integrations/slack), you can acknowledge incidents directly from Slack without opening the dashboard. Hyperping tracks who acknowledged each incident and how long it took, so you can measure MTTA and MTTR across your team.
## Post incident updates to a Slack channel
The Slack Incident Manager integration posts to your preferred Slack channel every time you manually publish an incident to your status page. You can create a new channel for every incident, or use a permanent one. After connecting Slack, invite the **@Hyperping Ongoing Incident** bot to the channel of your choice.
Setup instructions are in the [notification channels guide](https://hyperping.com/docs/projects/notification-channels).
## Show your incident history
Resolved incidents remain visible in the incident history of your status page.
Moving from StatusPage.io? You can bring your historical incidents and maintenances with you using the [import tool](https://hyperping.com/docs/status-page/import-from-statuspage).
> **Want a month-at-a-glance view of this history?**
>
> Enable the [incident calendar](https://hyperping.com/docs/status-page/incident-calendar) to show past incidents and upcoming maintenances on a monthly calendar at the bottom of your page.
## Automate incidents with the API
Everything above can be done programmatically. The [Incidents API](https://hyperping.com/docs/api/incidents) lets you list, create, update, and delete incidents, and add updates to an existing incident, using the same update statuses as the dashboard. Titles and update text accept localized values for multi-language status pages.
For example, create an incident with its first investigating update:
```bash
curl -X POST https://api.hyperping.io/v3/incidents \
-H "Authorization: Bearer ${API_TOKEN}" \
-H "Content-Type: application/json" \
-d '{
"title": {
"en": "We are investigating the issue",
"fr": "Nous enquêtons sur le problème"
},
"type": "outage",
"affectedComponents": ["comp_123"],
"statuspages": ["sp_123"],
"updates": [
{
"date": "2023-10-01T13:00:00Z",
"text": {
"en": "We are investigating the issue",
"fr": "Nous enquêtons sur le problème"
},
"type": "investigating"
}
]
}'
```
**Response201 Created**
```json
{
"uuid": "inci_cDAqydvnNnyc8D",
"date": "2023-10-01T13:00:00.000Z",
"title": {
"en": "We are investigating the issue",
"fr": "Nous enquêtons sur le problème"
},
"type": "outage",
"affectedComponents": ["comp_123"],
"statuspages": ["sp_123"],
"updates": [
{
"uuid": "upd_abc123",
"date": "2023-10-01T13:00:00.000Z",
"text": {
"en": "We are investigating the issue",
"fr": "Nous enquêtons sur le problème"
},
"type": "investigating"
}
]
}
```
Start with [Create an incident](https://hyperping.com/docs/api/incidents/create) and [Add an update](https://hyperping.com/docs/api/incidents/add-update).
AI agents can publish, update, correct and resolve status page incidents, and declare, acknowledge and escalate the incidents that page your on-call team, through the [MCP server](https://hyperping.com/docs/mcp).
## Next steps
[
Subscribers→
Email, Slack, Teams, and SMS notifications for your visitors.
](https://hyperping.com/docs/status-page/subscribers)[
Incidents API→
List, create, update, and delete incidents programmatically.
](https://hyperping.com/docs/api/incidents)[
Public post-mortems→
Publish what happened and what you changed once an incident is resolved.
](https://hyperping.com/docs/status-page/post-mortems)[
Import from StatusPage.io→
Bring your historical incidents and maintenances with you.
](https://hyperping.com/docs/status-page/import-from-statuspage)
[← Incident calendar](https://hyperping.com/docs/status-page/incident-calendar)[Custom domain →](https://hyperping.com/docs/status-page/custom-domain)
[](https://x.com/hyperping)[](https://www.linkedin.com/company/hyperping)
© 2026 Hyperping
---
Source: https://hyperping.com/docs/status-page/languages
# Multi-language status pages
Serve your status page, your service names, and every incident update in more than one language.
A status page has one default language, and can carry any number of additional ones. Once a second language is on, everything a visitor reads becomes translatable: the page description, your service names, and the text of each incident and maintenance update. Visitors pick their language from the page itself.
This matters when:
- Your customers are spread across countries and read your status page during an outage, which is the worst moment to ask them to parse a second language
- You operate in a market where communicating in the local language is expected, or required
- Your support team already answers in several languages and the status page is the one place that does not
## Available languages
English, French, German, Dutch, Polish, Russian, and Swedish. Any of them can be the default, and any of them can be added alongside it.
> **Plan availability**
>
> Choosing your default language works on every plan. Adding more languages requires the Pro plan.
## Set it up
1. Open the Languages settings
Go to [Status Pages](https://app.hyperping.io/v2/statuspage), pick your page, then open the **Languages** category.
2. Pick your default language
The **Default language** is what every visitor sees first, and the language your service names and updates fall back to.
3. Add the others
Add each language you want under **Additional languages**. They appear as tags you can remove later.
4. Translate what visitors read
Your service names and page description now show one input per language. Fill them in, then hit Publish.
## Writing incidents in several languages
With more than one language enabled, the incident and maintenance editors show a language tab above each text field. Write the title and each update once per language, and the visitor sees the version matching their choice.
A language tab you leave blank publishes blank, so during a fast-moving incident the pragmatic move is to write the same text in every tab first and refine the translations afterwards. Editing an update later works exactly like editing any other incident update.
> **Check every tab before you publish**
>
> Nothing blocks you from publishing an update with only one language filled in, and subscriber notifications go out with whatever you wrote. If a large part of your audience reads another language, it is worth a glance at the tabs before hitting publish.
## How visitors choose
A language picker appears on the status page once a second language is enabled. The page opens in your default language, not in the visitor's browser language, and their choice is remembered in their browser for the next visit.
## Languages in the machine-readable outputs
| Output | Behavior |
| --- | --- |
| [RSS and Atom feeds](https://hyperping.com/docs/status-page/rss-atom-feeds) | Served in the default language, or another one with `?lang=fr` |
| [Public API](https://hyperping.com/docs/status-page/public-api) | Returns a `title` object keyed by language code |
| [status.json](https://hyperping.com/docs/status-page/status-page-json) | Language independent, it carries no text |
## Troubleshooting
**I cannot add a second language**
Additional languages require the Pro plan. The default language selector stays available on every plan.
**An incident update looks empty in one language**
That language tab was left blank when the update was published. Open the incident, fill the tab in, and save. An update written before you added a second language is not affected: text typed while the page had a single language is reused for every language you add later.
**I removed a language and the translations are gone**
Removing a language drops the text written for it. Re-adding the language gives you empty fields again, so export or copy anything you want to keep before removing one.
**The language I need is not in the list**
Tell us which one through the chat or by email. Adding a language means translating the interface strings on our side, so it is a request we act on rather than a setting you can flip.
## Next steps
[
Publish incidents→
Write updates, including the per-language tabs.
](https://hyperping.com/docs/status-page/incidents)[
Add services→
Name and translate the services on your page.
](https://hyperping.com/docs/status-page/add-services)[
RSS and Atom feeds→
Serve your history per language with the lang parameter.
](https://hyperping.com/docs/status-page/rss-atom-feeds)[
Create a status page→
Every other setting of the status page builder.
](https://hyperping.com/docs/status-page/create-status-page)
[← White labeling](https://hyperping.com/docs/status-page/white-labeling)[SMS notifications →](https://hyperping.com/docs/status-page/sms-notifications)
[](https://x.com/hyperping)[](https://www.linkedin.com/company/hyperping)
© 2026 Hyperping
---
Source: https://hyperping.com/docs/status-page/migrate-to-v2
# Migrate to version 2
Learn how to migrate your status page to our revamped version.
Our status page product has been revamped to a second, much improved version.
Some of the new features involve:
- **Static served** - Allows to serve ultra-fast status pages
- **Hosted on a reliable hosting provider** - rather than an in-house solution.
- **Private/internal status pages** - Using Google SSO
- **Updated design**
- **Multi-lang support**
- **TV Mode/auto refresh stats**
- **Light/Dark modes**
- **Fixes and improvements from the v1**
- **Updated designs of incident emails**
## Switch to V2
1. Open Status Pages
If you already have a version 1 status page, when clicking "Status Pages", you will be redirected to the "https://app.hyperping.io/statuspage" page.
2. Click "Switch to v2"
To view the v2 status page, click the "Switch to v2" button at the top-right of the Status Page's view. You will then be redirected to a "https://app.hyperping.io/v2/statuspage" page. You can switch back to v1 at anytime.
Learn more about [how to create a status page](https://hyperping.com/docs/status-page/create-status-page) (v2).
> **The v1 is no longer maintained**
>
> We recommend migrating to the new status page version as soon as possible, as we are not maintaining the v1 anymore.
## Need help?
Whether you need help or don't have the time, we can help migrate your status page ourselves by replicating your v1 over the v2.
We will take care of migrating your subscribers over your new status page as well.
Do not hesitate to ask us via the chat or via email at hello@hyperping.io.
### Do not forget about the CNAME record!
> **Update your DNS record**
>
> Old status pages were using the _status.hyperping.io_ CNAME record. With the newer version, you now must use _cname.hyperping.io_.
## Next steps
[
Create a status page→
Every customization option in the v2 status page builder.
](https://hyperping.com/docs/status-page/create-status-page)[
Custom domain→
Point your domain at cname.hyperping.io with automatic HTTPS.
](https://hyperping.com/docs/status-page/custom-domain)[
Import from StatusPage.io→
Bring your historical incidents and maintenances with you.
](https://hyperping.com/docs/status-page/import-from-statuspage)[
Go-live checklist→
Everything to verify before you announce your new page.
](https://hyperping.com/docs/status-page/go-live-checklist)
[← Footer badge](https://hyperping.com/docs/status-page/footer-badge)[Import from statuspage.io →](https://hyperping.com/docs/status-page/import-from-statuspage)
[](https://x.com/hyperping)[](https://www.linkedin.com/company/hyperping)
© 2026 Hyperping
---
Source: https://hyperping.com/docs/status-page/post-mortems
# Public post-mortems
Explain what happened after an incident, on the status page your customers already check.
Once an incident is resolved, you can attach a written post-mortem to it. It appears at the top of the incident on your status page, above the updates you posted during the outage. Visitors see a **Postmortem - Read details** line in your incident history and the full text on the incident page. You write it in the dashboard, keep it as a draft while your team reviews it, and publish it when it is ready.
- Tell customers what caused an outage and what you changed so it does not happen again.
- Answer the "what happened yesterday?" emails with a single link.
- Give security reviewers and enterprise buyers a public record of how you handle incidents.
In the incident history, a published post-mortem shows as the newest entry of the incident
## Key terms used in this article
- **Public post-mortem**: the write-up you publish on the status page, attached to a status page incident.
- **Internal post-mortem**: the write-up on the Post-Mortem tab of an alerting incident, under **Incidents**. It stays in the dashboard and never reaches your status page.
- **Draft**: a post-mortem that is saved but not published. Only your team can see it.
See the [Glossary](https://hyperping.com/glossary) for a full list of terms.
> **Plan availability**
>
> Post-mortems are published on status page incidents, which are included in paid plans. See the [pricing page](https://hyperping.com/pricing) for details.
## Write and publish a post-mortem
Go to [Status Pages → Updates → Choose an incident](https://app.hyperping.io/incidents) to open the incident you want to explain.
1. Open a resolved incident
Once the latest update of an incident is **Resolved**, a **Public post-mortem** block appears at the top of its timeline. To start one before the incident is resolved, open the **...** menu next to the incident title and select **Write post-mortem**.
2. Click Write post-mortem
The editor opens with a template: Summary, Impact, Root cause, Resolution, and What we are changing. Replace each section with your own text, or delete the ones you do not need.
3. Write each language
On a multi-language status page, the editor has one tab per language. A language you leave empty shows the text of the page's default language.
4. Save a draft or publish
Click **Save draft** to keep working on it without showing it to visitors, or **Publish** to add it to every status page the incident is published on.
The editor, with the same formatting tools as incident updates
The editor supports headings, bold, italic, strikethrough, inline code, links, and bulleted or numbered lists. Anything else, such as scripts, embedded frames, or inline styles, is removed when you save.
## Start from your internal post-mortem
If the status page incident was published from an alerting incident that already has an internal post-mortem, the block offers a second button: **Start from internal post-mortem**. It copies the internal text into the editor so you do not start from a blank page.
Read it through before you publish. The internal version was written for your team: it usually names people, internal systems, and action items that customers do not need to see. The public version works best when it covers what customers experienced, the cause in plain language, and what you changed.
The [post-mortem template playbook](https://hyperping.com/docs/playbooks/post-mortem-template) covers how to run the internal review itself.
## What visitors see
A published post-mortem is the newest entry of the incident timeline, dated with its publication date:
- In the incident history and the recent incidents on your home page, the entry reads **Postmortem - Read details**. Clicking it opens the incident page.
- On the incident page, the entry shows the full post-mortem. You can link to it directly by adding `#postmortem` to the incident URL.
The labels follow the visitor's language on multi-language pages.
On the incident page, the post-mortem sits above the updates posted during the outage
## Edit, unpublish, or delete
Once saved, the post-mortem shows in the incident timeline of the dashboard with a **Draft** or **Published** label. Open its **...** menu to change it:
| Action | What happens on your status page |
| --- | --- |
| **Edit** | A published post-mortem is updated as soon as you click **Save**. It keeps its original publication date, so fixing a typo does not move it. |
| **Publish** | The draft appears on every status page the incident is published on. |
| **Unpublish** | The post-mortem is removed from the status page and kept as a draft. |
| **Delete** | The post-mortem is removed from the status page and from the dashboard. This cannot be undone. |
A published post-mortem in the dashboard, above the incident updates
On the alerting incident, the Post-Mortem tab shows whether the public version is written, in draft, or published, with a link to it.
## Examples
- Two days after a regional API outage, a SaaS team publishes the root cause and its new deploy safeguards, then links the post-mortem in its reply to every customer who opened a ticket.
- After a payment provider failure, an e-commerce team explains how it failed over and what it will do next time, so customers know the problem is handled.
- A company whose status page is in English and French writes both versions in the same editor and publishes them together.
## Troubleshooting
**The post-mortem does not show on my status page**
Check that it is published: a draft only shows in the dashboard. Then check that the incident is published on that status page, in the **Status pages** list of the incident. Status pages refresh within a few seconds of publishing.
**The Write post-mortem button is missing**
The block appears once the latest update of the incident is **Resolved**. Before that, use **Write post-mortem** in the **...** menu next to the incident title.
**Do subscribers get notified when I publish?**
No. Publishing a post-mortem does not send email, SMS, Slack, or Teams notifications. To notify subscribers, post an **Update** on the incident with a short summary and a link to the post-mortem.
**Can I publish a post-mortem through the API?**
Not yet. The [Incidents API](https://hyperping.com/docs/api/incidents) manages incidents and their updates. Post-mortems are written in the dashboard.
## Next steps
[
Publish incidents→
Post updates while you work through an incident.
](https://hyperping.com/docs/status-page/incidents)[
Post-mortem template→
Run the internal review before you write the public version.
](https://hyperping.com/docs/playbooks/post-mortem-template)[
Subscribers→
Email, Slack, Teams, and SMS notifications for your visitors.
](https://hyperping.com/docs/status-page/subscribers)[
Incident calendar→
Show past incidents on a monthly calendar.
](https://hyperping.com/docs/status-page/incident-calendar)
[← Publish incidents](https://hyperping.com/docs/status-page/incidents)[Incident calendar →](https://hyperping.com/docs/status-page/incident-calendar)
[](https://x.com/hyperping)[](https://www.linkedin.com/company/hyperping)
© 2026 Hyperping
---
Source: https://hyperping.com/docs/status-page/private-status-pages
# Private status pages
Protect your status pages with Password protection, Google SSO, email access codes, or single sign-on through your company's identity provider, over SAML or OpenID Connect.
Page access options in your status page settings
Go to [Status Pages → Choose a status page → Settings → Page Access](https://app.hyperping.io/v2/statuspage) to configure access controls.
> **Which access control should you pick?**
>
> Password protection is the simplest: one shared password. Email access codes restrict access to specific people or teams without requiring SSO infrastructure. Google SSO fits teams already using Google Workspace, and SSO connections cover enterprise identity providers like Entra ID, Okta and Auth0.
Pro includes 3 public or private status pages, password protection, email access codes, and multilingual pages. Google SSO and SSO connections for status page visitors require Business; SSO connections are billed separately.
## Password protection
Require a shared password to access your status page. Simple and effective for basic access control.
Toggle "Password protection" and set your password. You can edit the password at any time.
## Google SSO
Allow users to sign in with their Google account. Perfect for teams already using Google Workspace.
#### Allowed domains
You will need to add allowed email domains in order to let anyone with "@yourcompany.com" domains log in to the status page.
1. Open the allowed domains settings
Go to Status Pages → Choose a status page → Settings → "Allowed emails domains" section.
2. Add a domain
An email will be sent to this email address to confirm it.
## Email access codes
Restrict access to specific email addresses or entire domains. Visitors enter their email, receive a 6-digit code, and are granted access once verified. Codes expire after 10 minutes.
This is ideal when you want to restrict access to specific people or teams without requiring SSO infrastructure.
### Setting up access rules
1. Turn on the email whitelist
Go to **Status Pages → Choose a status page → Settings → Users**, then toggle "Email whitelist" on.
2. Add your access rules
Manage your access rules in the **Access rules** tab. You can add two types of rules:
- **Allowed domains**: anyone with an email at that domain (e.g. `*@acme.com`) can request access.
- **Individual emails**: whitelist specific email addresses. Use "Bulk add" to paste multiple emails at once.
Access rules: allowed domains and individual emails
### How visitors sign in
When a whitelisted user visits the protected status page, they enter their email address. If it matches a rule, a 6-digit access code is sent to their inbox. They enter the code and are granted a session.
The 6-digit access code verification
Sessions and active users can be monitored and revoked from the **Sessions** tab.
## SAML SSO
Sign in with enterprise identity providers like Microsoft Entra ID, Okta, Google Workspace, Auth0, and any other SAML or OpenID Connect provider. The **SAML SSO** option covers both protocols, through reusable SSO connections that can protect multiple status pages. The full walkthrough, from creating a connection to attaching it to a page, is in [Status page SSO](https://hyperping.com/docs/status-page/sso).
### SSO Connections
Create and manage SSO connections from **Status Pages → SSO Connections**. Each connection can be used on multiple status pages.
Creating an SSO connection
Click **New connection**, pick your identity provider, name the connection, and click **Create connection**. The connection card then guides you through the configuration for your provider.
### Pricing
| Provider | Price |
| --- | --- |
| Direct SAML (Azure AD, Okta, Google Workspace) | $49/mo |
| OpenID Connect (Auth0, Keycloak, Okta, Entra ID, and more) | $49/mo |
| Other providers (JumpCloud, OneLogin, Ping Identity, etc.) | $99/mo |
## Next steps
[
White labeling→
Remove Hyperping branding and send emails from your own domain.
](https://hyperping.com/docs/status-page/white-labeling)[
Custom domain→
Serve your status page from your own domain with automatic HTTPS.
](https://hyperping.com/docs/status-page/custom-domain)[
Subscribers→
Let visitors subscribe to updates over email, Slack, Teams, and SMS.
](https://hyperping.com/docs/status-page/subscribers)[
Go-live checklist→
Everything to verify before you announce your status page.
](https://hyperping.com/docs/status-page/go-live-checklist)
[← Subscribers](https://hyperping.com/docs/status-page/subscribers)[Status page SSO →](https://hyperping.com/docs/status-page/sso)
[](https://x.com/hyperping)[](https://www.linkedin.com/company/hyperping)
© 2026 Hyperping
---
Source: https://hyperping.com/docs/status-page/public-api
# Status page public API
Read your incidents and scheduled maintenances as JSON, straight from your status page.
Every status page serves two public JSON endpoints alongside the page itself. They need no API key, they return the same history your visitors see, and they use the response shapes statuspage.io publishes, so integrations written against a statuspage.io page keep working once you switch.
Reach for them when:
- You are building your own status widget, banner, or in-app notice
- An internal tool needs to mirror your incidents without scraping HTML
- A dashboard tracks the status of several vendors, yours among them
- You are migrating from statuspage.io and would rather not rewrite what already consumes the feed
> **Not the same thing as the REST API**
>
> These endpoints are public, read-only, and scoped to one status page. To create incidents, manage subscribers, or read data across your whole account, use the authenticated [Status Pages REST API](https://hyperping.com/docs/api/statuspages) on `api.hyperping.io` instead.
## Endpoints
| Endpoint | Returns |
| --- | --- |
| `GET /api/v1/incidents.json` | Incidents and outages |
| `GET /api/v1/scheduled_maintenances.json` | Maintenance windows |
Both live on your status page domain, so a page on `status.acme.com` serves `https://status.acme.com/api/v1/incidents.json`. The Hyperping-hosted slug works the same way.
## Incidents
```bash
curl https://meta.hyperping.app/api/v1/incidents.json
```
**Response200 OK**
```json
[
{
"id": "6kddbqdycckq",
"start_date": "2026-07-06T23:18:06.000Z",
"end_date": "2026-07-07T00:38:17.000Z",
"name": "EU voice call phone number unavailable",
"title": { "en": "EU voice call phone number unavailable" },
"type": "incident",
"status": "resolved",
"link": "https://meta.hyperping.app/history/inci_MiabOZOm5ObN2h"
}
]
```
### Query parameters
| Parameter | Type | Default | Description |
| --- | --- | --- | --- |
| `status` | string | all | Filter by incident status |
| `type` | string | all | Filter by incident type |
| `limit` | integer | 50 | Results per page, 50 maximum |
| `page` | integer | 1 | Page number |
### Status values
| Value | Meaning |
| --- | --- |
| `ongoing` | No resolved update yet |
| `resolved` | Closed with a resolved update |
| `investigating` | Currently being investigated |
| `identified` | Cause has been identified |
| `update` | Progress update posted |
| `monitoring` | Fix deployed, watching for stability |
### Type values
`outage` for service outages, `incident` for everything else.
### Examples
- `/api/v1/incidents.json?status=ongoing` returns only what is unresolved right now
- `/api/v1/incidents.json?type=outage&status=resolved` returns resolved outages
- `/api/v1/incidents.json?limit=20&page=2` pages through the history
## Scheduled maintenances
```bash
curl "https://meta.hyperping.app/api/v1/scheduled_maintenances.json?status=upcoming"
```
**Response200 OK**
```json
[
{
"id": "t4btxayrds4g",
"start_date": "2026-08-15T14:30:00.000Z",
"end_date": "2026-08-15T18:30:00.000Z",
"name": "API infrastructure upgrade",
"title": { "en": "API infrastructure upgrade" },
"status": "upcoming",
"link": "https://meta.hyperping.app/history/mw_6ckvtMuyDhMfto"
}
]
```
### Query parameters
Same `limit` and `page` as incidents, plus a `status` filter with its own values:
| Value | Meaning |
| --- | --- |
| `upcoming` | Scheduled for the future |
| `inprogress` | Running right now |
| `completed` | Finished |
| `all` | Every maintenance window |
With no `status` parameter you get upcoming and ongoing windows only, which is what a "what is coming up" widget usually wants.
## Response fields
| Field | Type | Description |
| --- | --- | --- |
| `id` | string | Stable identifier for the entry |
| `start_date` | string | ISO 8601 start of the incident or window |
| `end_date` | string | ISO 8601 end, once there is one |
| `name` | string | Title in the page's default language |
| `title` | object | Title keyed by language code, for [multilingual pages](https://hyperping.com/docs/status-page/languages) |
| `type` | string | Incidents only: `outage` or `incident` |
| `status` | string | Current status, from the values above |
| `link` | string | Permalink to the entry on your status page |
## A live reference on your own page
Every status page hosts its own copy of this reference at `/docs`, filled in with your domain. Send integrators to `https://status.acme.com/docs` and they get the endpoints, parameters, and example responses without needing a Hyperping account.
## Access and caching
Both endpoints are open to anonymous requests on public pages and send `Access-Control-Allow-Origin: *`, so a browser front-end can call them directly without a proxy.
On a [protected page](https://hyperping.com/docs/status-page/private-status-pages) they answer 401 unless the request carries a valid session, the same rule the [feeds](https://hyperping.com/docs/status-page/rss-atom-feeds) follow. Publishing an incident update clears the cache immediately, so a poller sees a new incident on its next request.
## Troubleshooting
**The endpoint returns a 401**
The status page is password or SSO protected. These endpoints only serve anonymous requests on public pages.
**I get fewer results than expected**
`limit` is capped at 50 per request. Page through with `page=2`, `page=3`, and so on rather than raising the limit.
**Maintenance windows I know about are missing**
Without a `status` parameter the endpoint returns upcoming and ongoing windows only. Add `?status=all` to include completed ones.
**I need the current up or down state, not history**
Use the [status.json endpoint](https://hyperping.com/docs/status-page/status-page-json). It returns a single indicator and an uptime percentage, which is what a badge or a health check wants.
## Next steps
[
Status page JSON→
Current status and uptime in one small payload.
](https://hyperping.com/docs/status-page/status-page-json)[
RSS and Atom feeds→
The same history, for feed readers instead of code.
](https://hyperping.com/docs/status-page/rss-atom-feeds)[
Status Pages REST API→
The authenticated API for creating and managing pages.
](https://hyperping.com/docs/api/statuspages)[
Import from statuspage.io→
Move over and keep your existing integrations pointed at the same paths.
](https://hyperping.com/docs/status-page/import-from-statuspage)
[← Status page JSON](https://hyperping.com/docs/status-page/status-page-json)[Footer badge →](https://hyperping.com/docs/status-page/footer-badge)
[](https://x.com/hyperping)[](https://www.linkedin.com/company/hyperping)
© 2026 Hyperping
---
Source: https://hyperping.com/docs/status-page/rss-atom-feeds
# RSS and Atom feeds
Let anyone follow your incident history in a feed reader, without giving you an email address.
Every status page can serve its incident history as an RSS feed and an Atom feed. Feed readers, Slack's built-in RSS app, internal dashboards, and vendor status aggregators poll them directly. Nobody subscribes, so there is no list to manage and nothing to unsubscribe from.
Feeds are useful when:
- Customers want incident updates but will not hand over an email address
- You want incidents to land in a Slack channel through Slack's RSS app
- You are moving from statuspage.io and people already poll your feed URL
- An internal tool or an aggregator tracks the status of several vendors at once
## Feed URLs
Both feeds live at fixed paths on your status page domain:
| Format | URL | Content type |
| --- | --- | --- |
| RSS 2.0 | `/history.rss` | `application/rss+xml` |
| Atom 1.0 | `/history.atom` | `application/atom+xml` |
On a custom domain that gives `https://status.acme.com/history.rss`. The Hyperping-hosted slug works too: `https://acme.hyperping.app/history.rss`.
These are the same paths statuspage.io uses, so feed readers and integrations pointed at your old page keep working once the domain points to Hyperping. See the [import guide](https://hyperping.com/docs/status-page/import-from-statuspage) for the rest of the migration.
```bash
curl https://meta.hyperping.app/history.rss
```
## Turn feeds on
1. Open your status page settings
Go to [Status Pages](https://app.hyperping.io/v2/statuspage), pick your page, then open the **Notifications** category.
2. Enable RSS & Atom feeds
Turn on the **RSS & Atom feeds** toggle. Both feed URLs appear underneath, with a copy button on each.
3. Publish
Hit Publish. The feeds are live straight away.
New status pages have feeds on by default. Pages created before feeds shipped keep them off until you flip the toggle, so an older page returns a 404 on both URLs until then.
> **Available on every plan**
>
> Feeds are not a notification channel. They have no subscribers and cost nothing to serve, so they work on all plans and they are independent of the [Subscribers](https://hyperping.com/docs/status-page/subscribers) toggle. You can run a page with feeds on and subscriptions off.
## What the feed contains
Each feed carries the 25 most recent incidents and maintenance windows, sorted by latest activity. An incident that gets a new update moves back to the top, so a reader surfaces it again instead of leaving it buried under newer entries.
Every entry holds:
- The incident title and a link to its page on your status page
- A publication date (when the incident started) and an updated date (its most recent update)
- The full update timeline in the body, newest first, each one labelled Investigating, Identified, Update, Monitoring, or Resolved
- The list of affected services
- For maintenance windows, the scheduled start and end
```markup
Jul 20, 16:12 UTC
Identified - A bad gateway deploy.
Affected services: API, Dashboard
]]>