Resolve alerts automatically when a service recoversResolve an alert

An alert ends when a person acknowledges it or when the sender reports that the problem cleared. Resolve it from your code when the service recovers on its own.

POST/v1/alerts/resolve

curl https://acciti.com/v1/alerts/resolve \  -H "Authorization: Bearer $ACCITI_TOKEN" \  -H "Content-Type: application/json" \  -d '{ "user": "your-user-key", "dedupKey": "db-down" }'

Use the dedupKey the alert was raised with. Every open alert under that key closes: repeats stop, pending pushes are cancelled, and the escalation stops wherever it had reached, including the copies already sent to others on the rotation.

One key can have several open alerts. A metric that warns and then goes critical raises two, because the second is more urgent and doesn't collapse into the first. The response says how many closed.

{  "count": 2,  "alertIds": ["0198e3…", "0198e2…"],  "noticeId": "0198e4…"}

A count of zero is a normal answer. It means the service recovered before anyone was alerted.

By message ID

If you kept the ID from the send, resolve that message directly.

curl -X POST https://acciti.com/v1/messages/$MESSAGE_ID/resolve \  -H "Authorization: Bearer $ACCITI_TOKEN"

What the recipient sees

If the alert made a sound, the recipient gets a quiet follow-up at priority -1. Send message to set its text, or notify: false to skip it. Alerts that arrived silently or were held for a digest get no follow-up.

Both endpoints are idempotent and never overwrite an acknowledgement. An alert someone acknowledged stays acknowledged by them.

Connectors resolve alerts without code. Grafana posts firing then resolved, Better Stack posts an incident then its recovery, and the second rule ends the alert the first one raised. The two rules match on the condition field they both render.