Configuration done — now prove it works. You'll trigger a run on demand rather than waiting for the schedule, then read the run results the same way you would when investigating a real incident.
Run the monitor on demand
Waiting an hour for the schedule to prove your setup works is a poor feedback loop. Running the monitor manually executes the same cloud run your schedule would, so you can confirm the collection, environment, and runner all work together right now.
- Select your monitor in the Services sidebar.
- Click Run.
- Wait for the run to finish — a two-request collection usually completes in well under a minute.
Expected outcome: A new bar appears in the Run summary graph, and the monitor's sidebar status changes from Unknown to Healthy (or Unhealthy if something failed — you'll fix that in the next step).
Manual runs are labelled as such in the results, so you can filter them out later and compare only scheduled runs when you're looking at performance trends.
Troubleshooting: If the run errors immediately or every request comes back with no response, the usual cause is an unresolved {{baseUrl}} — go back to Step 3 and confirm the Monitoring environment is attached to the monitor and baseUrl is set in the Shared Value column.
Confirm a healthy, passing run
A run that merely finished isn't the same as a run that passed. This final step is the one that proves the whole chain works end to end: the monitor ran, your assertions actually executed, and every one of them passed — which is exactly the signal a real monitor exists to give you.
- With your monitor open, look at the Run summary graph. A red bar means tests failed or errors occurred during that run.
- Each request in the run is listed with its response code, response time, and which assertions passed or failed.
- Use the All, Passed, Failed, and Errors tabs to filter. Confirm your two status-code tests are in the Passed tab.
- Click the Console Log tab to see the run's stages and any
console.logoutput from your scripts. This is where you'd start when diagnosing a failure. - Re-run the monitor if you had a failure, and confirm the status icon is Healthy.
Know the difference between the four run results, because they point at different problems:
| Result | Meaning |
|---|---|
| Successful | The run completed and every test passed. |
| Failure | The run completed, but one or more tests failed — your API responded, just not correctly. |
| Error | The run couldn't complete: a network problem, TLS handshake, or a syntax error in a script. Check the Console Log. |
| Abort | The run exceeded the maximum runtime (10 minutes on Free, 15 on paid plans). |
Troubleshooting: If your assertions show a total of 0, the monitor ran but found no tests — revisit Step 2 and make sure the test scripts are on the Post-response tab and saved.
Next, explore viewing monitor results in depth, or read troubleshooting monitors and the monitor FAQs.