Kunobi Ping: your monitoring alerts, as push notifications

An alert can be correct and still fail. The rule has the right threshold, the condition is real, the notification goes out within seconds. Then it lands in an inbox or a Slack channel, and from that point on it depends on somebody being at a screen.

That last hop, from a system knowing something to a person knowing it, is usually the least engineered part of the stack: a chat-to-SMS bridge, a relay bot nobody wants to own, a webhook service someone wrote and left. Full incident-management platforms close the gap, but they assume you already run rotations and escalation policies and want the process that comes with them.

Ping covers just the delivery part. It's on the App Store and Google Play today.

What Ping is

Ping is a phone app and a webhook. Your monitoring tool posts an alert to an ingestion URL. The API key on that request identifies a team, and every signed-in phone on the team gets a native push notification. From there the incident lives in an inbox where you can read it, filter it and acknowledge it.

Grafana, SigNoz, Alertmanager, vmalert, Thanos and Mimir each get an endpoint that understands their payload, so incidents arrive with title, summary, service and severity already filled in. Anything else that can send an HTTP POST uses the generic endpoint. Include a dedup_key and repeats update the existing incident instead of opening a new one, so a flapping alert doesn't page the team twice.

Who's on it, and is it still firing?

Every incident answers two separate questions. Has someone dealt with it? That's status: open, acknowledged or resolved, and your team drives it. Is the condition still there? That's source state: firing, cleared, no data or monitor error, and only the monitoring tool changes it.

Source state has four values instead of a cleared flag because a monitor that has gone quiet and a monitor that is throwing errors both tell you nothing about production, and that's not the same as watching the condition recover. Ping keeps the difference visible.

Severity (critical, warning or info) is set by the producer and shown as-is.

The inbox

Each card shows severity, the affected service and how long ago it landed. Chips filter by severity or down to what still needs attention, and the header keeps a count of both next to the last sync time. Swipe left to acknowledge without opening; swipe right to clear it from your own list. Both give you an Undo first, and clearing changes only your view, not the team's.

Two timestamps can differ: when the producer says the incident occurred and when the backend received it. The detail screen shows both, labelled, and when one is missing or unparseable you get a dash rather than a guess.

Keys point at teams, not people

Every API key belongs to a team. Your personal team reaches only your devices, which is right for a monitor only you care about. A shared team reaches everyone on it, which is what an on-call rotation wants. You choose once, when you create the key, and every alert sent with it follows.

That's what makes handoffs painless. Add someone to the team and their phone starts receiving its alerts; no monitor gets edited. Revoke a key and alerts sent with it stop immediately, while the other keys on the team keep working.

The push is a doorbell, not the message

Phones decide when apps get to run, so Ping doesn't trust the notification payload to carry state. The push says something changed; the app then fetches the incident from the backend, which stays the source of truth for state and history. The inbox also refreshes when you open it or pull down. If a background wake never fires, you see the change on the next refresh instead.

Getting started

Three steps:

1. Create an API key in the Ping tab of your Kunobi profile. Scope it to a team and set an expiry if you want one. The secret is shown once.
2. Point your monitoring tool's webhook at https://api.kunobi.ninja/api/webhooks/<tool>, passing the key as a bearer token, an x-api-key header or the Basic-auth password.
3. Install the app and sign in with your Kunobi email. The device registers itself: no pairing code, no QR.

Or send a first alert by hand:

curl -sS -X POST https://api.kunobi.ninja/api/webhooks/raw \
  -H "Content-Type: application/json" \
  -H "x-api-key: $PING_API_KEY" \
  -d '{"source":"grafana","dedup_key":"checkout-5xx-01","title":"Payments API is down","summary":"Elevated 5xx on checkout","service":"payments-api","severity":"critical"}'

In Grafana that's a webhook contact point with the key as the password, in Prometheus a webhook receiver in your Alertmanager config, in SigNoz an alert channel.

The docs cover the full path: getting started, per-tool setup and the generic webhook fields, and team routing. The product page is the short version.

The app is on the App Store and Google Play.