saysOK vs Checkly

Checkly runs browser checks written with Playwright, and API checks, on a schedule. saysOK is built around what happens after a check fails: on-call, incidents and the status page your customers read.

# client-alertsSample data
saysOK 02:14
SEV-1 Incident Opened
Acme shop is down
Incident
INC-2841
Affected
Acme shop
Source: saysOK | Workspace: Northside Studio
AcknowledgeResolve
  • 02:14:07 Slack · #client-alerts sent
  • 02:14:08 Phone call · Maya, on call this week answered
  • 02:15:31 Acknowledged by Maya

Side by side

saysOK's column is what its plans include today. Checkly's is what its pricing page said on Oct 16, 2026; check there for current figures.

What is comparedsaysOKCheckly
Price
Paid plans$19 or $79 a monthPro or Team, flat per workspace$24 or $64 a monthStarter or Team, billed yearly; its page does not state monthly prices
People included5 or 10 seatsPro or Team; $4 a month per extra seat on Team3 or 10 usersStarter or Team
Free plan10 monitors5 min interval, 1 status page10 uptime monitors1,000 browser and 10,000 API check runs a month; checks stop when they run out
Checks
Uptime monitors50 or 250Pro or Team50 or 75Starter or Team; 25 more for $8
Fastest check30 sec or 15 secPro or Team, up to 3 million or 15 million checks a month1 min or 30 secStarter or Team
Browser checksOn TeamSteps in a list: go to, fill, click, wait, expect text or URL, screenshot3,000 or 12,000 runs a monthStarter or Team, as Playwright runs; more runs sold per 1,000
When a check fails
Phone call alerts20 or 100 a monthPro or TeamTeam only200 a month
On-call and escalationIncludedNot described
Incidents and post-mortemsIncludedNot described
Status pagesIncluded3 or unlimited, Pro or Team, each on your own domainAn add-on$9 or $30 a month on Starter or Team, billed yearly

What happens at 02:14 with saysOK.

One night at a made-up product, step by step: what saysOK does on its own, what your team sees, and what your customers read.

Your teamSample dataYour status page
  1. Your teamThe check from Frankfurt gets HTTP 503From api.acme.example/health. One region only, so nobody is paged yet.
    02:14:00
  2. Your teamVirginia sees it too: incident openedSEV-1. Maya, primary on call, gets a push notification and the Slack message at once.
    02:14:07
    Your status page“We are investigating an issue affecting API.”Nobody typed it: the page and its subscribers are updated from the incident.
  3. Your teamMaya acknowledgesFrom the Slack message. The secondary on call is never woken.
    02:16:30
  4. Your teamChecks pass from every region: resolvedThe incident resolves itself, and the Slack message says so.
    02:29:50
    Your status page“This incident has been resolved.”API is operational again, and subscribers are told.
  5. Your teamThe post-mortem is writtenStarted from the incident's timeline.
    09:30:00
    Your status pageThe post-mortem goes on the pageUnder the incident, for customers to read.
Down for
15 min 50 s
Customers told
at 02:14
Status updates typed
none

Which one fits

Neither is right for everyone. This is how we would choose.

Choose Checkly if

  • Your team writes Playwright tests and wants the same code to run as monitors.
  • You run many browser checks, or need more locations than saysOK has.
  • Writing checks as Playwright code matters more to you than on-call and incidents.

Choose saysOK if

  • What matters most is who gets paged, and what your customers read while you fix it.
  • You want on-call, incidents, post-mortems and status pages included, not added on.
  • Your checks are uptime, API and SSL checks, with a browser check or two for sign-in or checkout.

What saysOK includes

Part of the product, not sold as an add-on.

On-call, with a next person if nobody answers

A schedule says who is primary and who is secondary each day. An alert rule pages them in steps: when an alert is not acknowledged in time, the next person is paged.

On-call right nowSample data
Maya Keller
primary · until Mon 09:00
Jonas Berg
secondary · until Mon 09:00
Escalation policy
  1. at once Slack · #alerts
  2. +5 min Primary on-call, if not acknowledged
  3. +10 min Secondary on-call, if still not acknowledged

Every incident keeps its record

A timeline of what was detected, who acknowledged and when it was resolved, with a severity from SEV-1 to SEV-4. Write the post-mortem from it and publish it to your status page.

INC-2841SEV-1ResolvedSample data
  1. 02:14:07Detected: Acme shop is down
  2. 02:14:08Maya paged by phone call
  3. 02:15:31Acknowledged by Maya
  4. 02:31:10Resolved: checks passing again
Post-mortem: Acme shop outage
root cause · customer impact · 2 action items
Published

Cron jobs and backups, next to the uptime checks

A heartbeat monitor expects a ping from each scheduled job and alerts when one does not arrive, so a backup that silently stopped is found the same day.

HeartbeatsSample data
Nightly database backupevery 1 day · last ping 3 hours ago
On time
Invoice exportevery 1 hour · last ping 2 hours ago
Missed
# crontab: report in when the backup has run
0 3 * * * backup.sh && curl -fsS https://saysok.com/api/heartbeats/YOUR_TOKEN/ping

An API, and a way in for AI assistants

Monitors, incidents and heartbeats are reachable over a public REST API. The MCP endpoint lets assistants such as Claude Code and Cursor work with them too.

REST APIExample
curl https://api.saysok.com/v1/monitors \
  -H "Authorization: Bearer YOUR_API_KEY"
Claude Code, over MCP
claude mcp add --transport http saysok https://api.saysok.com/mcp --header "Authorization: Bearer YOUR_API_KEY"

Try it on your own sites.

The free plan covers 10 monitors and one status page. Move to Pro or Team when you need faster checks or seats for a team.