tutorial

Integrating Uptime Monitoring into Your CI/CD and DevOps Workflow via API

Programmatically create and manage Vigilmon monitors as part of your CI/CD pipeline — provision monitors on deploy, route webhooks to Slack/PagerDuty, and use GitOps patterns for monitoring config.

Most monitoring setups follow the same pattern: someone adds a monitor by hand after a service is deployed. The monitor URL might be slightly wrong. It gets forgotten when the service moves. Nobody notices until an outage goes undetected for an hour.

The fix is treating monitoring configuration as code — provisioned automatically on deploy, version-controlled alongside your application, and torn down when the service is decommissioned. This is what the Vigilmon API enables.

This guide walks through the complete integration: programmatic monitor creation on deploy, webhook routing to Slack and PagerDuty, Terraform and Ansible patterns, and a GitOps approach to keeping monitoring config in sync with your deployments.

Vigilmon REST API Overview

Vigilmon exposes a REST API that covers the full monitoring lifecycle:

| Resource | Endpoint | Operations | |---|---|---| | Monitors | /api/monitors | Create, read, update, delete, list | | Alert channels | /api/alert-channels | Create, list, delete | | Status pages | /api/status-pages | Create, update, list | | Incidents | /api/incidents | Read, list, acknowledge | | Reports | /api/reports | Read monitoring history and metrics |

All endpoints use standard HTTP methods and return JSON. Authentication uses Bearer tokens passed in the Authorization header.

Getting your API key:

  1. Log into vigilmon.online
  2. Navigate to Settings → API Keys
  3. Create a key with write access and store it securely

Monitor Creation on Deploy

The most direct integration point: create a monitor when a service deploys, delete it when the service is decommissioned. No manual steps, no drift.

Shell Script Pattern

A minimal monitor creation script, usable from any CI/CD system:

#!/bin/bash
# create-monitor.sh — call this from your deploy step

VIGILMON_API_KEY="${VIGILMON_API_KEY}"  # from CI environment variables
SERVICE_URL="${1}"                       # passed as first argument
SERVICE_NAME="${2}"                      # passed as second argument
ALERT_CHANNEL_ID="${VIGILMON_SLACK_CHANNEL_ID}"

response=$(curl -s -X POST "https://vigilmon.online/api/monitors" \
  -H "Authorization: Bearer ${VIGILMON_API_KEY}" \
  -H "Content-Type: application/json" \
  -d "{
    \"name\": \"${SERVICE_NAME}\",
    \"url\": \"${SERVICE_URL}\",
    \"type\": \"http\",
    \"interval\": 60,
    \"timeout\": 10,
    \"expected_status\": 200,
    \"alert_channel_ids\": [\"${ALERT_CHANNEL_ID}\"]
  }")

monitor_id=$(echo "$response" | jq -r '.id')
echo "Monitor created: ${monitor_id}"
echo "${monitor_id}" > .vigilmon-monitor-id  # save for teardown

Call this from your deploy pipeline:

# In your CI/CD deploy step
bash create-monitor.sh "https://api.yourservice.com/health" "API - production"

To delete on teardown:

#!/bin/bash
# delete-monitor.sh
MONITOR_ID=$(cat .vigilmon-monitor-id)
curl -s -X DELETE "https://vigilmon.online/api/monitors/${MONITOR_ID}" \
  -H "Authorization: Bearer ${VIGILMON_API_KEY}"
echo "Monitor ${MONITOR_ID} deleted"

GitHub Actions Integration

A full GitHub Actions workflow that creates a monitor after successful deployment:

# .github/workflows/deploy.yml
name: Deploy and Monitor

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Deploy application
        run: |
          # your deploy steps here
          echo "Deploying..."
        
      - name: Register uptime monitor
        env:
          VIGILMON_API_KEY: ${{ secrets.VIGILMON_API_KEY }}
          VIGILMON_ALERT_CHANNEL: ${{ secrets.VIGILMON_SLACK_CHANNEL_ID }}
        run: |
          MONITOR_RESPONSE=$(curl -s -X POST \
            "https://vigilmon.online/api/monitors" \
            -H "Authorization: Bearer ${VIGILMON_API_KEY}" \
            -H "Content-Type: application/json" \
            -d '{
              "name": "'"${GITHUB_REPOSITORY}"' - production",
              "url": "'"${{ vars.PRODUCTION_URL }}"'/health",
              "type": "http",
              "interval": 60,
              "expected_status": 200,
              "alert_channel_ids": ["'"${VIGILMON_ALERT_CHANNEL}"'"],
              "tags": ["github-actions", "'"${GITHUB_SHA}"'", "production"]
            }')
          
          echo "Monitor response: ${MONITOR_RESPONSE}"
          MONITOR_ID=$(echo "${MONITOR_RESPONSE}" | jq -r '.id')
          echo "VIGILMON_MONITOR_ID=${MONITOR_ID}" >> $GITHUB_ENV
      
      - name: Output monitor ID
        run: echo "Monitor ID: ${{ env.VIGILMON_MONITOR_ID }}"

Store secrets in GitHub Actions → Settings → Secrets and variables → Actions.

Webhook-to-Slack Integration

Vigilmon sends webhook payloads when monitors change state. Route these to Slack via an incoming webhook or a lightweight relay function.

Direct Slack Integration

In the Vigilmon dashboard, go to Alert Channels → Add Channel → Slack. Paste your Slack incoming webhook URL. Vigilmon will format and send alerts automatically when monitors go down or recover.

Custom Webhook Relay (for advanced routing)

If you need custom routing logic — different Slack channels for different service tiers, custom message formatting, or integration with an existing alerting bus — deploy a small relay function:

// webhook-relay.js — deploy as a serverless function
// Receives Vigilmon webhook payloads and routes to appropriate Slack channels

export default async function handler(req, res) {
  const { monitor, event, timestamp } = req.body;
  
  // Route by tag
  const isProd = monitor.tags?.includes('production');
  const slackWebhookUrl = isProd 
    ? process.env.SLACK_PROD_WEBHOOK
    : process.env.SLACK_DEV_WEBHOOK;
  
  const emoji = event === 'down' ? '🔴' : '🟢';
  const message = {
    text: `${emoji} *${monitor.name}* is ${event.toUpperCase()}`,
    blocks: [
      {
        type: 'section',
        text: {
          type: 'mrkdwn',
          text: `${emoji} *${monitor.name}* is *${event.toUpperCase()}*\nURL: ${monitor.url}\nTime: ${timestamp}`
        }
      }
    ]
  };
  
  await fetch(slackWebhookUrl, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify(message)
  });
  
  res.status(200).json({ ok: true });
}

PagerDuty Integration

Vigilmon's webhook payload can route to PagerDuty's Events API v2:

# Map Vigilmon webhook to PagerDuty event
# Run this via a webhook relay or serverless function

curl -s -X POST "https://events.pagerduty.com/v2/enqueue" \
  -H "Content-Type: application/json" \
  -d "{
    \"routing_key\": \"${PAGERDUTY_INTEGRATION_KEY}\",
    \"event_action\": \"trigger\",
    \"dedup_key\": \"vigilmon-${MONITOR_ID}\",
    \"payload\": {
      \"summary\": \"${MONITOR_NAME} is DOWN\",
      \"source\": \"vigilmon\",
      \"severity\": \"critical\",
      \"custom_details\": {
        \"url\": \"${MONITOR_URL}\",
        \"regions_affected\": \"${REGIONS}\"
      }
    }
  }"

For auto-resolution, send event_action: resolve with the same dedup_key when Vigilmon sends a recovery webhook.

Terraform Pattern

The cleanest IaC pattern uses the Mastercard restapi Terraform provider to create Vigilmon monitors as Terraform resources with full lifecycle management:

# terraform.tf
terraform {
  required_providers {
    restapi = {
      source  = "Mastercard/restapi"
      version = "~> 1.18"
    }
  }
}

provider "restapi" {
  uri                  = "https://vigilmon.online"
  write_returns_object = true
  headers = {
    Authorization = "Bearer ${var.vigilmon_api_key}"
    Content-Type  = "application/json"
  }
}

variable "vigilmon_api_key" {
  type      = string
  sensitive = true
}

# Create a monitor alongside any infrastructure resource
resource "restapi_object" "api_monitor" {
  path         = "/api/monitors"
  id_attribute = "id"

  data = jsonencode({
    name            = "API - ${var.environment}"
    url             = "https://${var.api_domain}/health"
    type            = "http"
    interval        = 60
    timeout         = 10
    expected_status = 200
    alert_channel_ids = [var.vigilmon_alert_channel_id]
    tags            = ["terraform", var.environment]
  })
}

terraform apply creates the monitor. terraform destroy deletes it. Monitor URL is derived from infrastructure outputs — no manual copy-paste.

Ansible Pattern

For teams using Ansible for deployment orchestration, a task that creates a Vigilmon monitor as part of a playbook:

# tasks/vigilmon.yml — include in your deploy playbook
- name: Create Vigilmon uptime monitor
  uri:
    url: "https://vigilmon.online/api/monitors"
    method: POST
    headers:
      Authorization: "Bearer {{ vigilmon_api_key }}"
      Content-Type: "application/json"
    body_format: json
    body:
      name: "{{ service_name }} - {{ environment }}"
      url: "{{ service_url }}/health"
      type: "http"
      interval: 60
      timeout: 10
      expected_status: 200
      alert_channel_ids:
        - "{{ vigilmon_alert_channel_id }}"
      tags:
        - "ansible"
        - "{{ environment }}"
        - "{{ ansible_date_time.date }}"
    status_code: 201
  register: monitor_response

- name: Store monitor ID for later use
  set_fact:
    vigilmon_monitor_id: "{{ monitor_response.json.id }}"

- name: Save monitor ID to host facts
  copy:
    content: "{{ vigilmon_monitor_id }}"
    dest: "/etc/vigilmon-monitor-id"

Add vigilmon_api_key to your Ansible vault. Reference vigilmon_monitor_id in teardown playbooks.

GitOps for Monitoring Config

For teams practising GitOps, monitoring configuration lives in the same repository as application code and is applied via CI/CD pipeline:

.
├── src/
├── kubernetes/
├── monitoring/
│   ├── monitors.yaml        # declarative monitor definitions
│   └── alert-channels.yaml  # alert channel config
└── .github/workflows/
    └── sync-monitors.yml    # applies monitoring config on merge

monitors.yaml (declarative format):

monitors:
  - name: "API - production"
    url: "https://api.yourcompany.com/health"
    interval: 60
    type: http
    expected_status: 200
    tags: [production, api, core]
    alert_channels: [slack-prod]
  
  - name: "App - production"
    url: "https://app.yourcompany.com"
    interval: 60
    type: http
    expected_status: 200
    tags: [production, frontend]
    alert_channels: [slack-prod]
  
  - name: "SSL - api.yourcompany.com"
    url: "https://api.yourcompany.com"
    type: ssl
    interval: 3600
    alert_channels: [slack-prod]

sync-monitors.yml (GitHub Actions workflow):

name: Sync Monitoring Config

on:
  push:
    paths:
      - 'monitoring/**'
    branches: [main]

jobs:
  sync:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Sync Vigilmon monitors
        env:
          VIGILMON_API_KEY: ${{ secrets.VIGILMON_API_KEY }}
        run: |
          # Read desired state from monitors.yaml
          # Compare with current monitors via GET /api/monitors
          # Create/update/delete to reach desired state
          python scripts/sync_vigilmon.py monitoring/monitors.yaml

This pattern ensures every production endpoint has a corresponding monitor definition in version control. Monitor changes are reviewed as PRs, rolled back with git reverts, and applied automatically on merge.

Practical Quickstart

If you want to verify the integration before building the full pipeline, here's a two-minute test:

# 1. Get your API key from vigilmon.online/settings/api-keys
export VIGILMON_API_KEY="your-api-key"

# 2. Create a monitor
curl -X POST "https://vigilmon.online/api/monitors" \
  -H "Authorization: Bearer ${VIGILMON_API_KEY}" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Test - API health",
    "url": "https://your-service.com/health",
    "type": "http",
    "interval": 60,
    "expected_status": 200
  }'

# 3. List your monitors
curl "https://vigilmon.online/api/monitors" \
  -H "Authorization: Bearer ${VIGILMON_API_KEY}"

If you get a 201 and see the monitor in the response, your API integration is working.

Summary

| Integration pattern | Use case | Complexity | |---|---|---| | Shell script on deploy | Any CI/CD system, fast setup | Low | | GitHub Actions workflow | GitHub-hosted projects | Low | | Webhook relay to Slack | Custom message routing | Medium | | Webhook relay to PagerDuty | On-call alerting integration | Medium | | Terraform restapi provider | IaC-managed infrastructure | Medium | | Ansible playbook task | Configuration-managed deployments | Medium | | GitOps declarative sync | Full declarative monitoring as code | High |

External uptime monitoring belongs in your CI/CD pipeline, not in a browser tab. When monitoring configuration is provisioned programmatically alongside your infrastructure, monitors don't drift, don't get forgotten, and don't require manual effort to maintain.

Get started at vigilmon.online — create your API key, add your first monitor programmatically, and integrate alerting into your existing CI/CD workflow.

Tags: #cicd #devops #api #monitoring #github-actions #terraform #ansible

Monitor your app with Vigilmon

Free plan — 5 monitors, no credit card required. Up and running in 60 seconds.

Start free →
← Back to all articles