Uptime Kuma → OpsPing

Last updated Nov 2, 2026.

Why not Uptime Kuma's Opsgenie notification?

Uptime Kuma's built-in Opsgenie notification only offers Opsgenie's US and EU API hosts; the URL is chosen from a region setting in the provider source ↗ and can't be pointed at another host. Use the generic Webhook notification instead, which takes any URL.

Setup

1. In OpsPing, open Integrations and create an inbound integration with the OpsPing API Key source type, which accepts native OpsPing JSON and auto-detected Alertmanager-style payloads. Name it after the sending system (the name becomes the alert source), pick a default service, and copy its webhook URL (https://api.opsping.com/v2/webhooks/inbound/<id>/<token>). Treat the URL as a secret: the token in it is the credential.
2. In Uptime Kuma, go to Settings → Notifications → Setup Notification (or edit a monitor and click Setup Notification) and choose Webhook as the notification type.
3. Paste the OpsPing webhook URL into Post URL.
4. Set Request Body to Custom Body and paste the template below. No extra headers are needed; leave Additional Headers empty.
5. Click Test, then Save, and enable the notification on the monitors that should page.

{
  "alerts": [{
    "status": "{% if heartbeatJSON == nil or heartbeatJSON.status == 0 %}firing{% else %}resolved{% endif %}",
    "fingerprint": "uptime-kuma-{{ monitorJSON.id | default: 'test' }}",
    "labels": {
      "alertname": {{ msg | json }},
      "severity": "critical",
      "instance": {{ monitorJSON.name | default: "Uptime Kuma test" | json }}
    },
    "annotations": {
      "description": {{ heartbeatJSON.msg | default: msg | json }}
    }
  }]
}

Uptime Kuma renders custom bodies with LiquidJS templates (webhook provider source ↗). The template sets status to firing when the heartbeat is DOWN (status 0) and resolved otherwise, and uses the monitor ID as the fingerprint, so each monitor owns exactly one OpsPing alert alias (uptime-kuma-<monitor id>).

Field mapping

Uptime Kuma value	OpsPing alert
msg	Message (Uptime Kuma's notification text, truncated to 130 characters)
monitorJSON.id	Alias uptime-kuma-<id>; dedupes repeat down events, closes on up
monitorJSON.name	Entity
heartbeatJSON.msg	Description (the check's error text)
severity label	Priority: the template sends critical (P1); change it to error, warning or info for P2–P4

Notes

• The Test button sends a message without monitor or heartbeat data, so the template opens a P1 alert with alias uptime-kuma-test. Close it by hand in OpsPing after testing; no up event will follow it.
• Use one Uptime Kuma notification per OpsPing integration (and default service) if different monitors belong to different services.
• Uptime Kuma must be able to reach api.opsping.com over HTTPS.

FAQ

Can I point Uptime Kuma's Opsgenie notification at OpsPing?

No. Uptime Kuma's Opsgenie provider only lets you pick Opsgenie's US or EU region and builds the API URL from that, so it cannot be pointed at OpsPing. Use the Webhook notification with the custom body on this page.

Do alerts close when the monitor comes back up?

Yes. An up heartbeat renders status: resolved with the same uptime-kuma-<monitor id> fingerprint, and OpsPing closes the alert that owns that alias, even if it was already acknowledged.

Which Uptime Kuma versions support this?

Any version whose Webhook notification has the Custom Body option with LiquidJS templates, which includes the 1.23 releases and 2.x. Older versions that only offer the preset JSON or form-data bodies can't produce this payload.