Webhook-Driven Uptime Alerting: Integrate GoPinger With Your Stack

Why Webhook-Driven Alerting Matters

Email and Slack are fine for human-facing alerts, but most production stacks also need alerts to flow into systems that are not humans: incident tools, on-call schedulers, ticketing systems, internal dashboards, chat bots, even ticket queues fed by other internal tooling. A webhook is the universal adapter that makes this work. Your monitoring tool sends a documented JSON POST. The receiving system parses it, correlates it, routes it, or transforms it. No integrations, no custom adapters per vendor — just HTTP.

The reason webhooks beat native integrations for anything beyond a handful of popular tools is that they compose. A webhook can feed ten different internal systems without your monitoring tool needing to know about any of them. If your company is running a mix of vendor tools and homegrown systems — as most teams are — webhook alerts scale with your stack in a way that first-class integrations do not.

Anatomy of a GoPinger Webhook Alert

Every GoPinger webhook is a JSON POST with Content-Type: application/json and User-Agent: GoPinger/1.0. The body is stable and documented for three event types: monitor.down, monitor.up, and test. Let us walk through each.

Monitor down event

Fired when an alert rule's condition is met (after consecutive-failure smoothing and consensus checks). This is the event your incident tool cares about most:

{
  "event": "monitor.down",
  "monitor_name": "api.acme.com",
  "monitor_url": "https://api.acme.com/health",
  "incident_id": "inc_8f3b2c",
  "cause": "HTTP 503 from 3 of 4 locations",
  "rule_name": "Monitor Down",
  "started_at": "2026-04-11T14:02:15Z",
  "timestamp": "2026-04-11T14:03:15Z"
}

The incident_id is stable across the entire lifecycle of the incident — you will see the same ID on the matching monitor.up event when the service recovers, which lets you correlate the two into a single logical incident without string matching.

Monitor up event

Fired when the service recovers. Includes the total duration of the incident in seconds:

{
  "event": "monitor.up",
  "monitor_name": "api.acme.com",
  "monitor_url": "https://api.acme.com/health",
  "incident_id": "inc_8f3b2c",
  "duration_seconds": 962,
  "resolved_at": "2026-04-11T14:18:17Z",
  "timestamp": "2026-04-11T14:18:18Z"
}

Feed this into your post-incident metrics pipeline to track mean-time-to-recovery automatically — no manual timestamping, no stopwatches.

Test event

Fired when an operator clicks "Send test alert" in the dashboard. It carries a distinct event value so your receiver can ignore or handle it specially, which means you can safely verify the delivery path without polluting production incident records:

{
  "event": "test",
  "monitor_name": "api.acme.com",
  "rule_name": "Monitor Down",
  "message": "This is a test alert from GoPinger.",
  "timestamp": "2026-04-11T14:00:00Z"
}

A Minimal Receiver in Python

The simplest possible webhook receiver — just enough to log and branch on event type — is under 20 lines:

from flask import Flask, request, abort

app = Flask(__name__)

@app.post("/gopinger")
def gopinger_webhook():
    if request.headers.get("User-Agent") != "GoPinger/1.0":
        abort(403)
    event = request.json
    if event["event"] == "test":
        return "", 204
    if event["event"] == "monitor.down":
        open_incident(event["incident_id"], event)
    elif event["event"] == "monitor.up":
        close_incident(event["incident_id"], event["duration_seconds"])
    return "", 204

For production you will want to add a shared-secret signature check (see next section), retry-safe idempotency via incident_id, and a structured logger. But the core is that small.

Securing Your Webhook Endpoint

Webhook URLs are public by nature — anyone who discovers the URL can POST to it. Secure the endpoint with one or more of these patterns, in order of effort:

• Unguessable URL — include a long random token in the path (e.g. /hooks/gp/8f3b2c...c9a4). Cheapest protection, but leaks if anyone ever logs the URL.
• IP allow-list — restrict inbound POSTs to the monitoring provider's egress IP range. Effective, but breaks if your monitoring tool's IPs change.
• Shared secret in a header — GoPinger's generic webhook does not currently sign payloads. A common workaround is to put a shared-secret token in the URL (as above) and validate it on receive. This covers 95% of the threat model for internal endpoints.

For endpoints that receive alerts about production systems, combine at least two of these. An unguessable URL plus an IP allow-list takes you from "discoverable" to "requires targeted knowledge of your infrastructure," which is usually enough.

Common Patterns: Four Real-World Integrations

Here are four integrations you can build on top of GoPinger webhooks in an afternoon. All four are something we have seen customers or ourselves actually ship.

Pattern 1: Paging bridge to PagerDuty

Receive the monitor.down event, transform it into PagerDuty's Events API v2 format, POST it to PagerDuty's ingest URL. On monitor.up, POST a resolve event with the same incident_id mapped to PagerDuty's dedup_key. A 40-line Lambda or Cloud Function handles the whole flow.

Pattern 2: Jira ticket auto-creation

On monitor.down, create a Jira issue in your incident project with title built from monitor_name and cause, and body containing the full event JSON. Store the mapping between incident_id and the Jira key. On monitor.up, transition the ticket to Done with a comment that includes duration_seconds.

Pattern 3: Custom Slack messages with actions

GoPinger's built-in Slack contact posts a plain incident message. If you want interactive buttons ("Acknowledge", "Open runbook", "Mute"), intercept the webhook instead and post your own Slack message via the Slack Web API with blocks. This is how more mature teams get a personalized incident UX without waiting for vendor feature releases.

Pattern 4: Incident metrics pipeline

Receive every monitor.down and monitor.up event and write them to a time-series store (InfluxDB, Prometheus Pushgateway, a datawarehouse). Build dashboards for monthly incident count, time-to-recovery distribution, and per-monitor reliability. Once duration_seconds is flowing into your metrics backend, SLO reporting is mostly a query away.

Practical Tips

A few things we have learned the hard way about webhook-driven alerting:

• Always handle the test event. If your receiver errors on event: "test", your verification path is broken and you will ship untested alerts. Return 2xx for test events, even if you do nothing with them.
• Make your receiver idempotent on incident_id. GoPinger does not retry on non-2xx, but networks drop packets, load balancers fail over, and you will eventually re-process the same event. Deduplicate on incident_id + event type.
• Do not log the full payload by default. Include incident_id and event type in logs; log the rest at debug level behind a flag. Incident metadata often contains internal URLs and hostnames you do not want in log aggregators forever.
• Keep the receiver fast. GoPinger's timeout is 10 seconds. If your webhook target takes longer than that, you miss alerts. Accept the payload, return 2xx, and do the heavy lifting asynchronously.

When Not to Use Webhooks

Honest counter-point: webhooks are overkill for teams whose entire alerting need is "tell me on Slack when a site goes down." If you have three monitors and one Slack channel, use the built-in Slack integration and move on. Webhooks start to pay off when you have multiple destinations (incident tool AND ticketing AND metrics), custom transformation needs (filter by severity, rewrite messages), or internal systems that nothing off-the-shelf talks to.

The rule of thumb: if "a different team would like to consume these alerts" ever comes up, it is time for webhooks.

A webhook is the uptime alert version of a shell pipe: small, well-defined, composable. You do not need to understand every downstream tool; you just need a stable contract on the wire.

Full feature details are on the alert contacts page — webhook is one of three contact types, alongside email and Slack Incoming Webhooks. See alert rules for the conditions that trigger a webhook, or read our guide on stopping alert storms before wiring webhooks to anything that pages humans. Free on every GoPinger plan — see pricing.