Guide
Deduplicate notifications from retried jobs
Retries are normal in automation. Deduplication works when the producer identifies the logical event rather than the individual delivery attempt.
Updated 6 min read
Build the key from stable inputs
Name the producer operation
Start with a bounded namespace such as release, backup or agent-run so unrelated events cannot collide.
Add the producer's durable identifier
Use a run ID, revision or scheduled window that remains identical across retries.
Add the outcome when outcomes are separate events
A publication failure and its later rollback can share a run ID but still need different event keys.
{
"title": "Publication rolled back",
"body": "Health checks failed after release 8f31a2; the previous image is live.",
"severity": "error",
"source": "release-worker",
"tags": [
"release",
"rollback"
],
"deduplicationKey": "release:8f31a2:rollback",
"metadata": {
"revision": "8f31a2",
"environment": "production"
},
"actions": [
{
"id": "open-release",
"type": "link",
"label": "Open release",
"href": "https://example.com/releases/8f31a2",
"style": "primary"
}
]
}Treat duplicate delivery as success
The first accepted request returns created true. A repeat with the same key in the same source returns the original identifier with created false. Both outcomes mean the logical event is present.
Frequently asked questions
- Does the producer need a special integration?
- No. The examples use an authenticated HTTPS request, so any script, service or visual workflow that can send HTTP can use the same contract.
- Should credentials be included in notification data?
- No. Keep credentials in the producer's secret store and send only the context needed to understand or locate the event.
Keep exploring
Put the pattern to work
Existing accounts can open the inbox and send their next event.