Deployments

Deployments let you tell IonHour when you're releasing new code. During a deployment window, IonHour can automatically pause affected checks so that expected downtime doesn't trigger false incidents and noisy alerts.

Why Use Deployment Windows

During a deployment, your service might restart, become briefly unavailable, or miss a heartbeat ping. Without a deployment window, IonHour would treat this as a real outage — creating incidents, sending alerts, and potentially waking someone up at 3 AM for a planned release.

Deployment windows prevent this by:

• Auto-pausing checks so missed signals are expected, not alarming.
• Suppressing DOWN/LATE transitions even if a signal is missed.
• Auto-resuming checks when the deployment ends.
• Recording deployment signals in the check's timeline for audit purposes.

Creating a Deployment

Deployments are project-scoped — each deployment is associated with a project.

From the UI

1. Navigate to a project's check detail view.
2. Use the deployment tools to create a new deployment window.
3. Fill in the details:

Field	Required	Description
Project	Yes	The project this deployment belongs to
Name	No	A label for the deployment (e.g., "v2.1.0 release")
Version	No	Release version identifier
Author	No	Who is deploying
Link	No	URL to the release, PR, or changelog
Auto-pause	No	Whether to pause checks during the deployment (default: off)
Checks	No	Specific check IDs to cover. If empty, covers all project checks.

From the API

curl -X POST https://app.failsignal.com/api/deployments \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "projectId": 1,
    "name": "v2.1.0",
    "version": "2.1.0",
    "author": "deploy-bot",
    "autoPause": true
  }'

The deployment starts immediately (startedAt defaults to now). If you need to schedule a future deployment, pass a startedAt value.

Auto-Pause Behavior

When autoPause is enabled and the deployment is created:

1. IonHour resolves the target checks — either the specific checks listed in checkIds, or all checks in the project if no IDs are specified.
2. Each target check is paused:
   • Status changes to PAUSED
   • The deploymentPaused flag is set
   • A DEPLOYMENT signal is recorded with the deployment metadata
3. All open incidents for paused checks are resolved immediately.
4. The IDs of actually-paused checks are stored in autoPausedCheckIds on the deployment record.

While paused, checks will not transition to LATE or DOWN, even if signals are missed.

Deployment Suppression

Even without autoPause, an active deployment window suppresses check status transitions. If a check in the project misses a signal while a deployment is active, IonHour won't transition it to LATE or DOWN.

This provides a lighter-touch approach — checks keep running and receiving signals, but missed signals during the deployment window don't trigger incidents.

Ending a Deployment

From the API

curl -X PUT https://app.failsignal.com/api/deployments/123/end \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{}'

Pass an optional endedAt timestamp, or omit it to end now.

When a deployment ends:

1. The endedAt timestamp is recorded.
2. If autoPause was enabled, all checks in autoPausedCheckIds are resumed:
   • Status changes to RESUMED
   • The deploymentPaused flag is cleared
   • A DEPLOYMENT signal is recorded with the end metadata
3. Normal monitoring resumes. The next missed signal will trigger the usual LATE/DOWN transitions.

Deployment History

View deployment history for a check in the check detail view. The history shows:

• Deployment name, version, and author
• Start and end times
• Duration (or "ongoing" if still active)
• Number of checks covered
• Link to the release (if provided)

You can also query deployment history via the API with date range and check filters:

# Deployments for a project in the last 7 days
curl "https://app.failsignal.com/api/deployments?projectId=1&start=2026-02-20&end=2026-02-27" \
  -H "Authorization: Bearer YOUR_TOKEN"

# Deployments covering a specific check
curl "https://app.failsignal.com/api/deployments?projectId=1&checkId=456" \
  -H "Authorization: Bearer YOUR_TOKEN"

Deployment Signals

IonHour records DEPLOYMENT signals in the check's signal timeline:

• Start signal: Created when the deployment begins (or when a check is paused). Includes metadata: deployment name, version, author, link.
• End signal: Created when the deployment ends (or when a check is resumed). Same metadata.

These signals appear in the check's signal history alongside regular heartbeat signals, giving you a clear audit trail of when deployments happened and how they affected monitoring.

Scoping Deployments to Specific Checks

By default, a deployment covers all checks in the project. If your deployment only affects specific services, pass checkIds to limit the scope:

curl -X POST https://app.failsignal.com/api/deployments \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "projectId": 1,
    "autoPause": true,
    "checkIds": [10, 11, 12]
  }'

Only checks 10, 11, and 12 will be paused. Other checks in the project continue monitoring normally.

CI/CD Integration

Add deployment windows to your CI/CD pipeline so they're created automatically with every release.

GitHub Actions Example

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Start deployment window
        id: deploy-start
        run: |
          RESPONSE=$(curl -s -X POST https://app.failsignal.com/api/deployments \
            -H "Authorization: Bearer $FAILSIGNAL_API_TOKEN" \
            -H "Content-Type: application/json" \
            -d "{
              \"projectId\": $PROJECT_ID,
              \"name\": \"$GITHUB_REF_NAME\",
              \"version\": \"$GITHUB_SHA\",
              \"author\": \"$GITHUB_ACTOR\",
              \"autoPause\": true
            }")
          echo "deployment_id=$(echo $RESPONSE | jq -r '.id')" >> $GITHUB_OUTPUT

      - name: Deploy application
        run: ./deploy.sh

      - name: End deployment window
        if: always()
        run: |
          curl -s -X PUT "https://app.failsignal.com/api/deployments/$DEPLOYMENT_ID/end" \
            -H "Authorization: Bearer $FAILSIGNAL_API_TOKEN"
        env:
          DEPLOYMENT_ID: ${{ steps.deploy-start.outputs.deployment_id }}

The if: always() on the end step ensures the deployment window closes even if the deploy step fails.

Best Practices

• Always end your deployments. An unclosed deployment window suppresses alerts indefinitely. Use if: always() in CI/CD or set a reasonable endedAt upfront.
• Use auto-pause for zero-downtime deploys that still restart. Even rolling deployments can cause brief monitoring gaps. Auto-pause prevents false alerts during the window.
• Scope to affected checks when possible. Pausing all project checks when only one service is being deployed creates blind spots for the unrelated checks.
• Include version and link metadata. When reviewing incident timelines later, deployment metadata helps correlate outages with specific releases.
• Integrate with CI/CD. Manual deployment windows are easy to forget. Automating them ensures consistency.