Deployments
Tell Ionhour when you're releasing code so a restart or missed heartbeat doesn't trigger a false incident.
Deployments let you tell Ionhour "we're releasing new code, expect some noise." During a deployment window, the affected checks and jobs won't be flagged as Late or Down just because a restart caused a brief gap in monitoring — so you don't get woken up for a planned release.
What a Deployment Does
When you start a deployment for a project, it covers either specific checks/jobs you pick or every check and job in that project. While the deployment is running:
- Missed heartbeats are ignored. Covered checks won't transition to Late or Down, even if a signal doesn't arrive on schedule.
- Auto-pause (optional). If you turn this on, Ionhour actively pauses the covered checks for the duration of the deployment and resumes them automatically when it ends. Any open incidents on those checks are resolved immediately when the pause kicks in.
- A record is kept. The deployment (name, version, author, release link) is logged and shows up later on the Incident Timeline, so you can tell whether an incident lined up with a release.
Auto-pause vs. plain deployment window
You don't have to turn on auto-pause. Without it, checks keep running as normal — Ionhour simply won't raise an alert for a missed signal while the deployment is active. Auto-pause is the stronger option: it puts the checks in a paused state for the whole window, which is useful for deploys with longer or less predictable downtime.
Creating a Deployment
There's no "New Deployment" button in the main navigation today — deployments are created programmatically, in one of two ways:
- From your CI/CD pipeline. Add a step to your deploy job that starts a deployment window right before the release runs, and ends it right after (whether the deploy succeeds or fails). This is the recommended approach for teams shipping regularly, since it needs no manual step.
- Directly via the API. Any tool that can make an HTTP request can start and end a deployment. See the API Reference for the request format.
While you're setting either of those up, the Deployment Tester in the Testing Lab lets you fire off a real deployment by hand — useful for confirming your project ID, check selection, and auto-pause behavior before you wire it into a pipeline.
Fill in the deployment details
- Choose the project the deployment belongs to.
- Give it a name (e.g. "Web API rollout").
- Optionally add a version, author, and a release link (a PR or changelog URL) — these show up later on the incident timeline and in deployment history.
- Turn on auto-pause if you want covered checks paused for the duration.
- Optionally set a scheduled start and end time, so the deployment activates and closes on its own instead of you having to end it manually.
- Under target checks, pick specific checks to cover, or leave it empty to cover every check in the project.
Start it, then end it when the release is done
Click Create deployment. If you didn't schedule an end time, click End deployment once the release has finished — either on the deployment card shown after creation, or by entering its ID.
Always end your deployment
An open-ended deployment keeps suppressing alerts on its covered checks indefinitely. If you're triggering deployments from CI/CD, make sure the "end" step runs even when the deploy step fails, so the window always closes.
Seeing Deployments on the Timeline
When a deployment lists specific checks under target checks, it appears as a marker on each of those checks' rows on the Incident Timeline, alongside status changes, incidents, and alerts. Hovering over a deployment marker shows its name and version and when it started — handy for a quick "was this incident caused by our last release?" check.
Project-wide deployments don't show timeline markers
If you leave target checks empty to cover every check in the project, alerts are still suppressed as expected, but the deployment won't appear as a marker anywhere on the Incident Timeline. To see a deployment on a check's timeline row, list that check under target checks explicitly rather than leaving the field empty.
Jobs also keep a Deployment history list in their Overview tab, showing past deployments that covered that job, how long each one ran, and a link to the release if one was provided.