2026-04-09

Webhook Integration for Uptime Monitoring: DevOps Guide

Webhook DevOps automation uptime monitoring

Are You Just "Receiving" Monitoring Alerts?

You've set up uptime monitoring and configured Slack or email alerts. But if humans still handle every incident manually, recovery times will suffer.

With webhook integration, you can trigger auto-recovery and escalation workflows automatically when downtime is detected. This article covers practical automation examples using Miterl's webhook notifications.

What Are Webhooks?

Webhooks send HTTP requests to a specified URL when events occur. In uptime monitoring, these events include:

monitor.down: Site went down
monitor.recovery: Site recovered
ssl.expiring: SSL certificate nearing expiration

// Example webhook payload
{
  "event": "monitor.down",
  "monitor": {
    "id": 1,
    "name": "ABC Corp - Corporate Site",
    "url": "https://abc-corp.example.com"
  },
  "incident": {
    "started_at": "2026-04-09T14:30:00+09:00",
    "status_code": 503,
    "response_time_ms": null
  }
}

Example 1: Auto-Recovery Scripts

When a web application process hangs, a restart often fixes it. You can automatically restart services when a webhook is received.

#!/bin/bash
# webhook-handler.sh — Auto-recovery script triggered by webhook

EVENT=$(echo "$REQUEST_BODY" | jq -r '.event')
MONITOR_URL=$(echo "$REQUEST_BODY" | jq -r '.monitor.url')

if [ "$EVENT" = "monitor.down" ]; then
  echo "[$(date)] Down detected: $MONITOR_URL — attempting auto-recovery"
  
  # Restart application server
  sudo systemctl restart php-fpm
  sudo systemctl restart nginx
  
  echo "[$(date)] Service restart complete"
fi

Important Notes

Auto-recovery is a temporary fix — root cause investigation is still necessary
Add safeguards to prevent infinite restart loops
Log all auto-recovery actions for later review

Example 2: CI/CD Pipeline Integration

If your site goes down after a deployment, you can automatically trigger a rollback.

# Trigger GitHub Actions rollback workflow
curl -X POST \
  -H "Authorization: Bearer $GITHUB_TOKEN" \
  -H "Accept: application/vnd.github.v3+json" \
  "https://api.github.com/repos/owner/repo/actions/workflows/rollback.yml/dispatches" \
  -d '{"ref": "main"}'

Deployment Flow Integration Pattern

Pre-deploy: Set a maintenance window to suppress alerts
Deploy: Execute deployment through CI/CD pipeline
Post-deploy: Monitoring automatically resumes after maintenance window ends
On failure: Webhook triggers rollback

Example 3: Incident Management Tool Integration

Send webhooks to PagerDuty, Opsgenie, or similar tools for automatic on-call escalation.

Add the webhook destination (such as your PagerDuty endpoint) as an alert contact in the dashboard. You can then list those contacts and their IDs via the API and attach them to each monitor through alert_contact_ids.

# List your alert contacts and their IDs
curl -s https://miterl.com/api/v1/alert-contacts \
  -H "Authorization: Bearer YOUR_API_KEY" | \
  jq '.data[] | {id, type, name}'

Example 4: Custom Dashboard Data Integration

Store webhook payloads in your database to build custom dashboards and reports:

Incident trend analysis: Patterns by day of week and time of day
MTTR tracking: Monitor mean time to recovery improvements monthly
Per-client reports: Detailed reports linked to status pages

Webhook Best Practices

Security

Signature verification: Validate the signature included in webhook requests to confirm the sender
HTTPS required: Always expose webhook endpoints over HTTPS
IP allowlisting: Restrict source IPs when possible

Reliability

Retry handling: Miterl retries webhooks when the receiver is temporarily unavailable
Idempotency: Design your receiver to handle duplicate webhook deliveries gracefully
Timeout: Return a response within 5 seconds

Implementing Webhook Signature Verification

Your webhook receiver is a publicly accessible HTTP endpoint, which means anyone can send a request to it. Signature verification ensures you only process payloads that genuinely originate from Miterl.

<?php
// PHP webhook signature verification example

function verifyWebhookSignature(string $payload, string $signature, string $secret): bool
{
    $expected = 'sha256=' . hash_hmac('sha256', $payload, $secret);
    return hash_equals($expected, $signature);
}

// On incoming request
$payload   = file_get_contents('php://input');
$signature = $_SERVER['HTTP_X_WEBHOOK_SIGNATURE'] ?? '';
$secret    = getenv('WEBHOOK_SECRET');

if (!verifyWebhookSignature($payload, $signature, $secret)) {
    http_response_code(401);
    exit('Unauthorized');
}

$data = json_decode($payload, true);
// Continue processing...

Use hash_equals() rather than === for the comparison. A standard string comparison is vulnerable to timing attacks; the constant-time comparison function eliminates that risk.

Feeding Incident Data into Monthly SLA Reports

Webhook payloads contain exactly the data you need for SLA reporting: incident start time, duration, recovery time, and affected monitor. Storing each payload as it arrives builds a queryable incident history that you can aggregate at month-end without touching the dashboard manually.

For agencies managing ten or twenty client sites, this is the foundation of a fully automated reporting pipeline. See the uptime SLA report guide for a complete walkthrough of what to include in client reports.

Summary

Webhook integration transforms uptime monitoring from a "notification tool" into an "automated response system." Auto-recovery, CI/CD integration, and escalation workflows dramatically improve incident response speed and quality.

For detailed webhook configuration, see the documentation. For notification setup, read "Setting Up Slack, Chatwork, and LINE Alerts." Try Miterl features by signing up for free. Check the FAQ for common questions.