Websites & Keywords

Check that a page answers with a healthy status, that a word or phrase is on it, or that a whole user flow — log in, search, check out — still works in a real browser.

Three monitor types cover websites. A Website monitor requests a URL and checks the status code. A Keyword monitor does the same and then looks for a piece of text in the response. A User journey monitor drives a headless browser through steps you record or script.

How a website check works

On every check, each selected region sends one HTTP request to your URL and waits for the full response. The check passes when the final response has a status code below 400. Anything from 400 up, or no response at all, fails it.

• Redirects are followed by default, up to five hops. The status that counts is the one at the end of the chain.
• A request that hasn't completed within Request timeout (30 seconds unless you change it) fails with a timeout.
• Requests carry a User-Agent header that starts with Zharp Uptime Bot, followed by a regular Chrome browser string.
• Each region's result is combined into one status for the monitor, as described in Core Concepts.

Each check also records where the time went — DNS lookup, TCP connect, TLS handshake, waiting for the first byte and content transfer — and the IP addresses the hostname resolved to. You see both on the monitor page.

Create a website monitor

1. 1
   Open the form

   On the Monitors page, click New. Under What should we monitor?, open the type picker and choose Website monitor. It is the default.

2. 2
   Enter the URL

   Fill in URL to monitor. If you leave off the scheme, https:// is added for you.

3. 3
   Choose who is alerted

   Under How should we escalate incidents?, keep Notify the on-duty member or pick an Escalation policy. See Escalation & On-call.

4. 4
   Adjust the request if you need to

   Open Advanced settings for the options in the table below, then click Create monitor. The first check runs within seconds.

For a bearer token, set Header name to Authorization and Header value to Bearer <token>.

SSL & domain verification

For an https:// URL, every check also reads the certificate and the domain's WHOIS record. The SSL & domain verification section decides what they do. It appears on website, keyword and API monitors, the checks that act on it; an SSL certificate monitor shows only SSL/TLS verification, beside its own expiry threshold, and domain, custom, crawler and scanner monitors don't show it.

Reminders are sent once a day, on the day the threshold is reached and again at 30, 14, 7, 3 and 1 days left (those within your threshold), through the monitor's alert settings.

When it goes down

A failed check records a message. Expand a failed row under Recent checks on the monitor page and it reads Check failed — followed by that message. The incident itself describes the cause in plain words.

The expiry reminders above are a heads-up, not an outage. To have the monitor itself go down ahead of an expiry, add an SSL certificate monitor or a domain expiry monitor.

Keyword monitors

A keyword monitor makes the same request as a website monitor. When the status check passes, it searches the response body for your text. By default the check fails if the text isn't there; under Match settings you can turn that around.

1. 1
   Choose the type

   Click New on the Monitors page and choose Keyword monitor in the type picker.

2. 2
   Enter the text and the page

   Fill in Keyword or phrase — for example All systems operational — and URL to monitor. Both are required.

3. 3
   Create it

   The request options under Advanced settings work the same as for a website monitor. Click Create monitor.

How the text is matched

• The search runs on the raw response the server returns — for a web page, its HTML source. Tags, attributes and inline scripts are part of what is searched.
• Matching is a plain substring search. It ignores case unless Case sensitive is set to Yes.
• No JavaScript runs. Text that the page only adds in the browser is not in the response and won't be found.
• The keyword is only looked for when the status check passed. A 500 fails on the status, not on the keyword.

The monitor page shows a Keyword match card with FOUND or MISSING, and two views of the last result: Visual, a screenshot with the keyword highlighted, and DOM, the page text around the first match.

Screenshots and the monitor page

Website and keyword monitors take a screenshot when the monitor's state changes: its first result, when it goes down, and when it recovers. Ordinary checks don't take one. The shot is a 1280×720 view of the page in Chromium, taken from the region whose result decided the change. For a keyword monitor the keyword is highlighted and scrolled into view; if it is missing, the shot carries a banner saying so. A capture that fails is retried, at most every 15 minutes. The screenshot is also attached to the incident.

A website monitor's page shows:

• The method and URL being checked, and a response time chart.
• Response breakdown — DNS lookup, TCP connect, TLS handshake, Waiting (TTFB) and Content transfer for the last check.
• The latest screenshot, for the state the monitor is in now.
• Domain & SSL — for an https:// URL, the domain's registration expiry and the certificate's validity, read alongside each check. Approaching expiry only sends reminders; with SSL/TLS verification on, an invalid certificate also fails the check.
• Recent checks — one row per check with region, status code and latency. Expand a row for the request and response headers, the response body (cut at 5,000 characters) and the timings.

User journey monitors

A User journey monitor runs a Playwright script in a headless browser on Zharp's servers. You can record the script by using your site, or write it yourself. The full guide is User Journeys.

Record a journey

1. 1
   Open the recorder

   Choose User journey monitor in the type picker, then click Open browser recorder.

2. 2
   Load your starting page

   Type the URL in the address bar and press Open. The page loads in a browser that Zharp runs, and you see it live. You can browse freely; nothing is captured yet.

3. 3
   Record

   Press Record and use the page. Clicks, typing, key presses and navigation become steps in the list beside the page. Switch from Interact to Assert and click an element to add a step that checks it is visible.

4. 4
   Stop and check it

   Press Stop. The Playwright script is generated and saved into the form. Use Replay to run the steps again, Re-record to start over, or Done to close the recorder.

A step whose selector looks fragile is marked with a warning icon. If a replay fails there, edit the step (its edit button, once the recording is stopped) or the script and use a steadier selector, such as a name or data- attribute.

Write the script instead

Click or edit the Playwright script manually to open the script editor. It starts with this example. The journey must contain a page.goto(...): its URL is where the journey starts.

import { test, expect } from '@playwright/test';

test('user journey', async ({ page }) => {
  await page.goto('https://example.com/login');

  await page.fill('[name="email"]', 'user@example.com');
  await page.fill('[name="password"]', 'secret');
  await page.click('[type="submit"]');

  await expect(page).toHaveURL(/dashboard/);
  await expect(page.locator('h1')).toContainText('Welcome');
});

Run Script runs it once from Zharp's servers with the browser settings below and shows the output, and the screenshot of the page when a run fails. Import lines are ignored; the script gets test, expect, page and console. It runs in an isolated sandbox with no access to Node.js modules, files or the server's environment; pages open over http(s) only, and private or internal addresses are blocked. Playwright's page and locator checks are supported — toHaveURL, toHaveTitle, toBeVisible, toBeHidden, toContainText, toHaveText, toHaveValue, toHaveAttribute, toHaveCount, toBeEnabled, toBeDisabled, toBeChecked and more, each with .not — and, as in Playwright, they keep retrying for up to 5 seconds (or the timeout you give them), so an element that appears late doesn't fail the run. See User Journeys for the full list.

Browser settings and failures

A run fails when any step or expect throws, or when it runs past Max duration. The message starts with Synthetic Check Failed: followed by the error, for example Synthetic Check Failed: Script execution timed out after 60000ms. The monitor page lists Recent runs with each step, how long it took, and the step that failed. With Screenshots on On failure or Always, the page as it stood at the failure is captured and attached to the incident, where website monitors' screenshots also appear. Zharp keeps the journey's latest final screenshot for each state (up and down); of the pictures taken along the way it keeps only where and when each was taken, not the images.

Troubleshooting

The site works in my browser but the check fails

• Firewalls and bot protection can block the check. Allow requests whose User-Agent starts with Zharp Uptime Bot.
• If only some regions fail, the monitor stays up, shows Failing in … under its status and alerts nobody. Look at the Location column in Recent checks to see which region failed.
• Slow pages fail once they pass the Request timeout. The Response breakdown shows which phase took the time.
• A server with a self-signed or internal certificate fails while SSL/TLS verification is on. Turn it off if that certificate is expected.

The keyword is on the page but isn't found

The check reads the HTML the server sends, not the page after JavaScript runs. Open the page's source (not the inspector) and search for the text. If it isn't there, use a User journey monitor with toContainText instead. Also check for markup inside the phrase: All <b>systems</b> doesn't match All systems.

A recorded journey fails on replay

Look at the failing step in Recent runs. Checks wait up to 5 seconds for an element; one that takes longer to load needs a longer check, such as await expect(page.locator('#results')).toBeVisible({ timeout: 20000 }), before the next click.