Check localhost with monito check --local
monito check --local runs the scenario against your dev server through a tunnel. HTTP only, three ports, and the CLI has to stay open.
Start the dev server, then:
monito check --local 3000 "The home page loads" --jsonOr name the URL. localhost, 127.0.0.1, [::1], and names ending in .localhost are local checks:
monito check http://localhost:3000/cart "The cart shows the added item" --timeout 600000 --jsonA second app on another port is a second --local. Three ports is the maximum. The first port is where the check starts when you do not pass a URL. Ports are 1024 through 65535. Local checks are HTTP. Local HTTPS is not supported.
What has to stay running
The CLI process and the dev server, until the verdict. --no-wait is refused. Editing files during the check can hot-reload the page under test.
Before the run is created, Monito sends a GET to the start path on 127.0.0.1, then tries ::1 if the connection is refused. Any HTTP response, including a 500, lets the check start. If nothing is listening, it stops with "Nothing is listening on localhost:3000. Start your dev server and retry." No run, no charge.
--project <projectId> files the run under that project, in its local (tunnel) environment.
What you do not get
Saved logins and request headers are not available. Use a dev login that the app already accepts, or a page that does not need one. A saved local check still cannot be monitored, scheduled, or put on a suite, an automation, or a status page. Those need a deployed environment.
Hosted MCP cannot reach localhost. Use monito mcp (the local server) or monito check. The local server accepts loopback URLs in check, with an optional localPorts list, and its tunnel stays up after a tool call's wait limit. Resume with wait_for_run.
Billing for a tunnel that never connects, a tunnel you close, and the five-check hourly limit is in when Monito's errors are free. The command reference is check.