Testing Lab
A sandbox for testing ping requests and deployment integrations before they matter for real.
The Testing Lab is a sandbox in the Explore section of Ionhour. It's the place to try things out safely — send test traffic to a URL, or simulate a deployment — before you wire an integration into production, or while you're debugging why a real Check or deployment isn't behaving the way you expect.
It holds two independent tools on the left — the Ping Tester and the Deployment Tester — plus a live Observation Panel on the right that shows what's happening across your workspace while you work.
What's real and what isn't
The Ping Tester doesn't create a monitored Check or Job — it's a one-off way to manually fire requests and watch what comes back. The one exception there: if you import settings from an existing Job (see below), the test sends real pings to that Job's real endpoint, so use that option with care if the Job is watching something in production. The Deployment Tester works differently and has its own warning further down this page — read it before using that tool.
Ping Tester
The Ping Tester lets you enter any URL and manually fire requests at it — on a repeating interval, for as long as you choose — so you can see whether it responds, what status code it returns, and how long it takes, all in real time.
Each URL you test is called a service. You can add more than one and run them all at once, which is handy for comparing a few endpoints or testing a whole integration at once.
Setting up a test
Add a service
- Go to Explore > Testing Lab.
- Click Add service to add a card for a new test target (one is already there to start with).
- Give it a name (optional — it just labels the card) and enter the URL you want to ping. It must be a full
http://orhttps://address.
You can also pick one of your existing Jobs from the Import from check dropdown to auto-fill its name, real ping URL, and schedule interval in one click — useful for manually re-testing a Job's integration.
Choose the request method, interval, and duration
Set the Method (GET or POST), how often to send the request (Interval, in seconds), and how long to keep the test running (Duration, in seconds).
Leave Method on GET. This is the default and covers most cases — you just want to confirm the URL responds and how fast.
Switch Method to POST. Two more fields appear:
- Headers (JSON) — any custom headers to send, as a JSON object (e.g.
{"Authorization": "Bearer ..."}). - Body — the request payload to send, e.g.
{"ping": true}.
Add more services (optional)
Repeat the steps above with Add service for each additional URL you want to test in the same run. Remove any card you don't need with its trash icon.
Start the test
Click Start all in the top-right toolbar. Every configured service begins firing requests immediately, then again on its own interval, until its duration runs out.
While a test is running, you can stop a single service from its card, or click Stop all to end the entire run early — you'll be asked to confirm since it aborts any in-flight requests.
Reading the results
While a test is running, a banner shows how many services are actively sending pings. Once every service finishes its duration (or you stop the run), a summary banner tells you whether everything passed or how many requests failed.
Alongside that, four live stats update as pings come in:
- Pings Sent — total requests fired so far.
- Success Rate — the percentage that came back with a successful (2xx) response.
- Avg Latency — mean response time across all requests.
- Failures — requests that errored out or returned a non-success status.
Each service's own card shows the same breakdown for just that URL — sent, OK, failed, and average latency — plus a progress bar while it's running.
The Observation Panel
While you work in either tool, the panel on the right stays visible and shows three things at once, so you can watch real effects without leaving the page:
- Check Status — a live list of your checks for the currently selected project, refreshing automatically while a test runs.
- Active Incidents — any currently open incidents, so you can immediately spot if something you're testing actually triggered a real incident.
- Request Log — a running, terminal-style feed of every request sent during your ping test, newest first, with its timestamp, status code (or error), and latency. Clear it any time with the Clear button.
Deployment Tester
The Deployment Tester lets you manually create and end a test deployment window, so you can confirm your deployment integration — and the behavior tied to it, like auto-pausing checks — is wired up correctly before you rely on it for a real release.
It lives in a collapsible Deployment section below your service cards (it shows an Active badge if a deployment is currently running for the selected project).
This creates a real deployment
Unlike the Ping Tester, the Deployment Tester is not a sandbox. Creating a test deployment here adds a real entry to that project's deployment history — the same history shown on the Deployments page and in dashboard charts — and it isn't marked as a test or removed afterward. If Auto-pause checks during deployment is on and you've selected target checks, those checks are genuinely paused for real while the deployment is active. Choose a project and checks you're comfortable affecting, and remember to click End deployment when you're done.
Fill in the deployment details
- Expand the Deployment section and choose the Project the test deployment belongs to.
- Optionally give it a Deployment name, version, author, and a link (e.g. to a release or commit).
- Toggle Auto-pause checks during deployment on if you want to confirm that checks actually pause while a deployment is active.
Choose which checks it applies to (optional)
Under Target checks, select one or more specific checks the deployment should apply to, or use Manual check IDs to enter a comma-separated list. Leave it empty to apply the deployment to every check in the project.
Create it, then end it
Click Create deployment to start the test deployment. Ionhour shows its details — status, auto-pause setting, and any scheduled times — right below the form. When you're done testing, click End deployment (the deployment's ID is auto-filled for you after creation).
Some workspaces also see optional Scheduled start and Scheduled end fields, for testing deployment windows that begin or end automatically at a future time rather than immediately.
Next Steps
Deployments
Understand deployment windows and how auto-pause protects checks during a release.
Checks
Monitor websites and APIs by having Ionhour probe them directly.
Jobs
Monitor cron jobs and background tasks via inbound heartbeat pings.
Incidents Overview
See how triggered incidents are tracked and resolved.