Pulse · an alternative to Checkly, Better Stack and UptimeRobot

It loads.
Does it work?

SiteOS Pulse checks your pages and the journeys visitors rely on, verifies pull requests before they reach production and follows errors to the logs, traces and replays behind them. This page compares SiteOS Pulse with Checkly, Better Stack and UptimeRobot on page and browser checks, pull request checks, alerts, check locations, status pages and price.

Page & Playwright checks
GitHub PR & code checks
Browser & server errors
Logs, traces & session replay

Start for free Read the guide

Free monthly execution credits. Monitoring and PR checks, together.

Compare

SiteOS vs Checkly, Better Stack & UptimeRobot

Start with what you need to verify: a responding URL, a working browser journey or a change before release. Compare the checks, evidence and workflow behind each tool.

SiteOS, Checkly, Better Stack and UptimeRobot: page and browser checks, PR verification, evidence and selected plans. Reviewed October 13, 2026.
Capability	SiteOS	Checkly	Better Stack	UptimeRobot
Free plan	Yes	Yes	Partly	Partly
Price of the compared plan	Free	Free	$39 / mo	€10 / mo
Page and uptime checks	Yes	Yes	Yes	Yes
Playwright browser journeys	Yes	Yes	Yes	No
Pull request preview checks	Yes	Yes	No	No
Code checks and secret scans	Yes	No	No	No
Scheduled checks	Yes	Yes	Yes	Yes
Failure alerts	Yes	Yes	Yes	Yes
Browser failure evidence	Yes	Yes	Yes	No
Public status pages	No	Yes	Yes	Yes
Checks from several locations	No	Yes	Yes	Partly
Heartbeat (cron job) monitoring	No	Yes	Yes	Partly
MCP for AI agents	Yes	Yes	Yes	Yes
Data export	Yes	Yes	Yes	Yes
One workspace with other website tools	Yes	Partly	Partly	No

YesPartly, with the condition in the notesNot offered or not documented

Better Stack and UptimeRobot also offer limited free tiers. Prices are the reviewed paid plans with monthly billing; UptimeRobot’s is in EUR. Better Stack adds $1 per 100 Playwright minutes.

Checkly runs checks in your CI/CD pipeline or through deployment integrations. SiteOS browser PR checks start from the GitHub deployment of the exact head commit, on any host and without a hosting account connection; code checks run on a hosted executor and do not replace general-purpose CI.

Pulse also collects errors, server logs and traces, browser request traces and masked replays of consented visits. Better Stack is an observability suite with incident response, on-call, logs and error tracking, and Checkly offers separate backend tracing. These are outside the compared rows.

For an alternative, “No” means the workflow was not documented in the reviewed sources (13 Oct 2026); it does not rule out APIs, integrations or CI-triggered monitoring. For SiteOS, it means Pulse does not offer it.

The status page, location and heartbeat rows were checked against each vendor’s official pages on 13 Oct 2026. UptimeRobot needs a paid plan to choose regions or add heartbeat monitors; Checkly’s Hobby plan uses 6 of its 22 locations.

Sources · reviewed 13 Oct 2026

How it works

From a check
to confidence.

Keep useful tests close to your code. Choose when they run, then investigate the actual result.

01
Define what works.
Check a page without code, or reuse a Playwright test and let Pulse update it from each deployed commit. Your agent can write the test and publish it to the right Project environment.
Set up website checks
02
Check the next change.
Connect GitHub and choose preview checks, code checks or both. Keep scheduled monitoring independent from pull request verification.
Verify pull requests
03
See what went wrong.
Open the failed step, recording or trace. Give your team and agent the same evidence, fix the issue and verify the result.
Read failure evidence

FAQ

Questions
about Pulse.

Pulse includes free monthly execution credits, shared across your organization’s Projects and environments. They continue beyond early access. Usage follows measured execution time, not a daily PR count. Check Usage & limits for your current allowance, renewal date and whether usage is estimated or charged against credits.

Yes. Pulse Errors collects browser exceptions, unhandled Promise rejections and server errors through the @siteoshq/pulse SDK, groups them into issues and shows original source locations from your uploaded source maps. It works independently of browser checks and can notify your team about new and regressed issues.

Yes. Keep your ordinary Playwright config and tests in the repository and save their setup in Pulse, with no Checks SDK or configuration file. With automatic updates on, Pulse refreshes the tests after each successful GitHub deployment of the configured environment and activates them only after a verification run passes. A browser Check can run on a schedule, on PR previews, in both contexts or only when requested. A page that only needs to respond or render can use a page Check without test code.

No. Pulse executes them on SiteOS runners and reports results to GitHub. Browser checks start from the GitHub deployment of the PR’s exact commit, on any host: hosts that report GitHub Deployments need no change, and other build systems run one CLI command after publishing. Code checks run published commands against the PR source and need no preview. Same-repository PRs are supported; forks and project Secrets are not available to PR runs.

Yes, when Trace is set up for the same Project environment. Browser checks note which tracking events the preview sends, by name only, and the GitHub Check adds an advisory Tracking section when something changed against your tracking plan, production or the last merged pull request. With the SiteOS Cookie banner as Trace’s consent source, passing checks also reopen up to three pages with Accept all and Reject all and flag tags that still send after Reject all. Neither changes the check result.

Yes, through PR code Checks on SiteOS’s hosted executor. Run Node.js package scripts for tests, lint or typechecking, or use the built-in committed-secret scanner. Code checks have a bounded environment: public npm dependencies, no project Secrets and no network during command execution. The guide lists supported package managers and limits.

No. Live monitoring and PR verification are separate. Monitoring confirms a problem after two consecutive eligible scheduled failures and resolves it after an eligible scheduled pass. Manual and PR runs do not open or resolve monitoring incidents. Runner infrastructure errors are not treated as website failures.

Yes. Pulse accepts server logs and traces through standard OpenTelemetry (OTLP/HTTP JSON), traces browser requests with the @siteoshq/pulse SDK and records masked replays of sampled visits after visitor consent. An error links to its trace and recording when they exist. Logs, traces and replays are kept for 7 days within fixed limits; request bodies, headers, cookies and query strings are never collected.

Yes. Pulse skills help your agent create, validate and publish checks. MCP exposes saved checks, runs, failure evidence, errors, logs and traces for the selected Project environment. Available screenshots, videos, traces and logs can also be downloaded by authorized team members. A saved report can be read without starting another run.

Know it works.
Keep it working.

One place for page and browser checks, pull request verification, errors and the evidence behind them.

Start for free Talk to our team

It loads.Does it work?

SiteOS vs Checkly, Better Stack & UptimeRobot

From a checkto confidence.

Define what works.

Check the next change.

See what went wrong.

Questionsabout Pulse.

Is Pulse free?

Does Pulse track website errors?

Can we reuse our Playwright tests?

Do PR checks need GitHub Actions?

Do PR checks show tracking and consent changes?

Can Pulse run unit tests, lint and secret checks?

Will a failed PR mark production as down?

Can Pulse show logs, traces and session replays?

Can our AI agent investigate a failure?

Know it works.Keep it working.

It loads.
Does it work?

From a check
to confidence.

Questions
about Pulse.

Know it works.
Keep it working.