Synthetic Checks & Uptime Monitoring

Synthetic checks probe your endpoints (or wait for your scheduled jobs to check in) on a schedule, so you find out about an outage from ScryWatch — not from a customer. When a check’s status changes, ScryWatch opens an incident, correlates it with recent deploys and open issues, and notifies your team.

What you’ll need

• A ScryWatch project
• A public HTTP(S) endpoint to monitor, or a scheduled job you want to heartbeat-monitor

Two kinds of checks

HTTP checks — ScryWatch fetches a URL you give it on a fixed interval and evaluates the response. Use these for APIs, websites, and health-check endpoints.

Heartbeat checks — ScryWatch generates a unique ping URL; your job (a cron, a batch process, a nightly script) calls that URL when it runs. If the expected ping doesn’t arrive in time, the check goes down. Use these for things that push rather than things you can poll — nightly billing runs, backup jobs, queue workers.

Step 1: Create an HTTP check

1. Click Checks in the left sidebar, then New Check.
2. Leave the type as HTTP and fill in:
   • Name — e.g. Checkout API
   • URL — the endpoint to probe, e.g. https://api.example.com/health
   • Interval — how often to probe: every 1, 5, or 15 minutes
   • Slow if > ms (optional) — a response-time SLO in milliseconds; probes slower than this are marked degraded even if the status code is fine
   • Body must contain (optional) — a substring the response body must include for the probe to count as healthy (a lightweight assertion, useful for {"status":"ok"}-style health endpoints)
   • Regions (optional) — check from multiple regions at once: US-West, US-East, EU-West, EU-East, APAC. Leave unselected to check from a single default region.
3. Click Create.

Note: Check URLs can’t target localhost, loopback addresses, or private/RFC1918 IP ranges (10.x, 172.16–31.x, 192.168.x, link-local 169.254.x) — only public hosts are probeable, since the check runs from ScryWatch’s infrastructure, not your network.

Step 2: Create a heartbeat check

1. Click New Check and switch the type to Heartbeat.
2. Fill in:
   • Name — e.g. Nightly billing job
   • Expected every — how often you expect a ping: hourly, daily, or weekly
   • Grace period — how long to wait past the expected interval before marking it down: 5 minutes, 10 minutes, or 1 hour
3. Click Create. ScryWatch shows you a ping URL — copy it.
4. At the end of your job, call the ping URL (GET or POST, either works):

curl https://api.scrywatch.com/api/heartbeat/<your-ping-token>

If no ping arrives within expected interval + grace period, the check flips to down. A heartbeat check that has never received a ping stays in a Pending state rather than immediately showing as down.

Step 3: Understand multi-region probing

When you select regions on an HTTP check, ScryWatch probes the URL from each selected region independently on every interval and aggregates the results:

• Majority of regions down → the check is down (a real outage, not one region’s network blip)
• Some but not a majority down or degraded → the check is degraded
• All healthy → the check is up

This avoids false alarms from a single region having a transient network issue while your service is actually fine everywhere else.

Step 4: Understand confirmation (anti-flap)

A single failed probe doesn’t immediately flip a check to down or degraded. ScryWatch requires 2 consecutive non-healthy probes before it changes the check’s status — a single blip stays on the previous status until it’s confirmed. Recovery is immediate: the very next successful probe after a failure brings the check back to up.

This means a check flapping between healthy and briefly-unhealthy won’t spam you with incidents for a single dropped request, but a real, sustained problem is still caught within two probe intervals.

Step 5: Incidents and notifications

When a check’s status is confirmed to change to down or degraded, ScryWatch:

1. Opens an incident for that check (if one isn’t already open)
2. Correlates the incident with any deploys shortly before it started, and counts open issues in the project — so you can see if the outage lines up with a recent release
3. Sends a notification to your project’s configured channels: Slack, Discord (via incoming webhook), and/or email

When the check recovers to up, the incident is resolved and a recovery notification is sent the same way.

Configure notification channels for checks the same place you configure them for alerts — in your project’s notification settings (webhook URLs and notification email addresses).

Step 6: View check status and history

The Checks page lists every check with a live status dot (up / degraded / down / pending) and when it was last checked. Click a check to expand it and see:

• Uptime (24h) — percentage of probes that succeeded in the last 24 hours
• Avg / p95 / p99 response time over the last 24 hours
• A response-time chart bucketed across the last 24 hours, with failed probes marked
• The “Why it changed” panel, when an incident is open or recent — showing correlated deploys and open issue counts

You’re done

You now know how to:

• Create HTTP checks with response-time SLOs and body assertions
• Create heartbeat checks for jobs that push rather than get polled
• Use multi-region probing to avoid single-region false alarms
• Understand how confirmation prevents incidents from flapping on a single blip
• Read check uptime, latency, and incident history from the dashboard

Related docs

• Alerts — condition-based alerting on log events, a different mechanism from check-based uptime monitoring
• Deploy Diff — the deploy correlation shown on check incidents comes from the same deploy markers