Status pages backed by browser tests

Publish journey status on your-app.monito.page from eligible Monito browser runs. Learn which checks count, how failures are confirmed and the plan requirement.

Monitoring · Checked 2026-10-23

Show visitors whether the journeys in your app work. Connect saved tests to public journeys, then publish a status page backed by scheduled browser checks.

How it works

  1. A schedule or deploy webhook starts saved tests on the environment your status page reports on, without a base-URL override.
  2. Monito checks the journeys in a browser. A first failure triggers a confirmation re-check before it can become a public failure.
  3. Eligible results update the journeys on your *.monito.page host. Visitors see states and freshness; you inspect the private browser evidence in Monito.

Set it up

Pro or Team to create and publish a status page. Scheduled runs and confirmation re-checks use credits. Plan details

  1. Open Status page in your project and choose Set up status page. Pick your-app.monito.page, the public name and the environment to report on.
  2. Edit journeys, give each a public name and description, and select the saved tests that prove it. A journey works only when all its tests pass.
  3. Add a schedule covering those tests on the selected environment. Preview the status page, then publish it.
  4. Use the public endpoints below in scripts or link the badge from a README. Replace your-app with the address you selected.
Configuration · bash
curl -fsS https://your-app.monito.page/status.json
curl -fsS https://your-app.monito.page/index.md

Read the published page as public JSON or Markdown. The host also serves /feed.xml and /badge.svg.

Example result

Example result: field names from the CLI, values illustrative

A CLI check --json diagnostic uses these verdict fields. It does not update your public status page. Public state comes from eligible saved-test runs; this illustrative diagnostic is not a status.json response.

Illustrative result · JSON
{
  "checkId": "check_example",
  "projectId": "project_example",
  "runId": "run_example",
  "done": true,
  "status": "failed",
  "cause": "product_defect",
  "causeLabel": "App bug",
  "durationMs": null,
  "creditsCharged": null,
  "reportUrl": "https://www.monito.dev/session/session_example",
  "firstFailure": "The cart total does not include shipping."
}

Limits to account for

Only schedule and deploy-webhook runs without a base-URL override count, plus status confirmation re-checks without an override. CI and API runs never count, with or without an override, including push-to-main CI runs. Manual runs, unsaved checks and repeat or fix-verification runs do not change the page.

A test version must pass once before its failures can count publicly. With confirmation re-checks enabled, a second failure confirms the first. With re-checks disabled, two scheduled failures in a row are needed.

Monito errors and setup problems leave a gap instead of declaring your app broken. Stale results show not verified since the last check, rather than continuing to claim the journey works.

Visitors see public journey names, states, times and incident text. Test instructions, internal URLs, bug reports, screenshots, recordings, credits and internal IDs stay private.

Custom domains are coming soon. Status pages are served on *.monito.page today.

Comparable benchmark runs

Our team published these runs in the reliability benchmark. They show comparable browser journeys, not executions of the configuration or illustrative result above. Run your own scenario before relying on this integration.

Benchmark method and limits

Read the full guide

All integrations