Run the same checks on every deploy
A saved check can run from a deploy webhook, CI, or a schedule. A status page publishes only scheduled and deploy-webhook results, and it needs Pro.
A one-off monito check is not a habit. Saving it (monito check save) makes a test you can run again. Three ways that run starts without you clicking:
After a deploy
A deploy webhook is an HTTP POST with the project's secret as a bearer token. A 202 means the tests were queued. It does not mean they passed. The body can name an environment, a suite, scenario ids, or a baseUrlOverride for a preview origin. Results land in the dashboard. The pipeline does not wait. If the pipeline should fail the build, use CI instead.
On a schedule
In the project: Automations → New automation → Schedule, on the environment you care about. The schedule is what a status page measures. This post does not name a default interval, because you set it, and the page shows the interval you set.
On a status page
Status pages need Pro. The page lists journeys you name. A journey works only when every test you attached to it passed.
What counts:
- Only scheduled runs and deploy-webhook runs. A run you start while editing, a CI run against a preview, and a repeat or fix-verification command do not move the page.
- The first failure is re-checked once (1 credit) before it is public, unless you turn re-checks off. Then two scheduled failures in a row are required.
- After you edit a test's instructions, its failures do not count until the new version has passed once.
- Monito's own problems are not your outage. A timeout, a model provider error, lost evidence, or a setup failure (missing login, failed fixture) leaves a gap, not a failure. So does a run whose browser got no answer: probes decide whether the site is responding.
- Without a fresh check — two schedule intervals — the journey reads "not verified since …", not "working."
Visitors see journey names and descriptions, states, times, check counts, uptime, and incident text. Test names and instructions, URLs, bug reports, screenshots, recordings, deploy details, credits, and internal IDs are never published. You get an email when the page changes state. Do not publish a journey whose failure would help an attacker (fraud checks, rate limits, 2FA, password reset).
A local check cannot be put on a schedule or a status page. It has no deployed environment to monitor.