Updates & Insights
Guides, tutorials, and news about Monito and developer tooling.
monito check --local runs the scenario against your dev server through a tunnel. HTTP only, three ports, and the CLI has to stay open.
Claude Code, Cursor, and Codex can run monito check or call the MCP server. The verdict comes back as JSON. Localhost needs the local server.
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.
Error means the check could not verify the scenario. It is not a pass, and it is not a verdict that your app is broken.
A run Monito could not finish is not charged. A failed check that found an app bug is charged. The difference is the cause.
Choose a test framework when you want code ownership and cheap repeat runs. Choose hosted QA when nobody owns the suite. An honest guide to both, including Monito's costs.
How to test SSO login the way it actually fails: SP- vs IdP-initiated flows, an SSO-enforced org that can still fall back to a password, a deprovisioned user who keeps access, and wrong-domain email. Plain-English prompts, no SAML library required.
Most cookie consent GDPR testing checks that the banner appears. The bug that gets you fined is a tracker firing before anyone clicked anything. Here's how to test cookie consent from the outside — watching which requests fire before, on reject, and after consent.
Record-and-playback testing feels like automation until the first redesign, when the recording breaks or, worse, silently passes. Here's why the recorded artifact was the liability all along — and what to keep instead of a suite of brittle click-paths.
Testing in production catches things staging never will. It also catches them after a real user already hit the bug. Why testing in production is a supplement to pre-merge verification, not a replacement for it — and the specific bug classes each one owns.