Documentation
Web & API checks
Web & API Checks monitor your own URLs and endpoints — that a page loads, that it contains the right text, that a button is present, or that an API returns the status, timing, and JSON you expect. Crowswatch runs each check on a schedule and records the history.
The four kinds of check
Open Web & API Checks in the sidebar and click New check. First, pick what you want to verify:
| Kind | Checks that… |
|---|---|
| Page loads | A page is reachable and renders |
| Text exists | A page contains specific text (e.g. “Thank you”) |
| Element exists | A button, link, or visible element is present |
| API / endpoint | A URL or API responds with the expected status, timing, and body |
Create a check
- Give the check a name (e.g. “Pricing page”).
- Choose a frequency: every 15 minutes, 30 minutes, hourly, every 6 hours, or daily. The default is every 30 minutes.
- Enter the URL to check (must be
httporhttps). - For Text exists, enter the expected text. For Element exists, enter the button/link text or a CSS selector.
- Optionally open Advanced options to tune what counts as failure (see below).
- Optionally assign a group to organise related checks.
- Click Create check.
What counts as failure (Advanced options)
Each kind exposes the controls that make sense for it:
Page loads & text/element checks
- Expected status and max response time (ms) — slower than the limit is flagged.
- Follow redirects and an optional expected final URL.
- Match type (contains/exact) and case sensitivity for text; must be visible / clickable and wait for page idle for elements.
API / endpoint
- Method, custom headers, and a request body.
- Expected status (e.g. 200) and max response time (e.g. 3000 ms).
- JSON validation rules: assert on a JSON path with operators like exists, equals, contains, greater than, and less than.
Multi-step journeys
Beyond single checks, Crowswatch can run synthetic journeys that walk through several steps — for example a revenue path (visit product → add to basket → open cart → click checkout) or a lead-form submission (visit → fill email → submit → expect “Thank you”). Each step is an action such as visit, click, fill a field, or verify text/element, run in order on the same schedule options as single checks.
Check history & uptime
Click any check to open its detail page. It shows history over 24 hours, 7 days, or 30 days, with per-check status, HTTP status code, and response time, plus summary tiles:
- Uptime % — the share of checks that were healthy or merely slow (degraded and failing runs count against it).
- Average response time and reliability rollups over longer windows.
Getting alerted
Alerts for checks are configured centrally on the Alerts page rather than inside the check dialog. Create an email or Slack channel, open its Web & API alerts tab, and choose which checks it covers and how many consecutive failures should trigger it (1–3), whether to send a recovery notice, and whether to flag slow responses. See the Alerts guide.
Permissions & limits
- Checks are scoped to the active team. Owners and admins create and edit them; members have read-only access.
- The number of checks is governed by your plan — Free 5, Pro 30, Team 100, Enterprise unlimited. Hitting the limit prompts an upgrade.
Troubleshooting
My check shows “blocked”
The target is serving bot-protection (e.g. a challenge page) to the checker. This is distinct from an outage — allow-list the checker or point the check at an endpoint that isn’t behind the challenge.
The endpoint is up but the check fails
Confirm the expected status matches what the endpoint actually returns, and that any JSON validation rules point at the right path. A response slower than your limit is recorded as slow, not down.
I can’t see 30 days of history
History retention is plan-gated. On the Free plan the range is capped at 7 days.