Overview
Webhook usage is measured per project and month.
Useful counters include:
- configured endpoints vs plan limit
- deliveries created this month
- successful deliveries
- HTTP attempts including retries
- bytes sent
One event delivered to three matching endpoints creates three webhook deliveries. A retry increases attempts and bytes but does not create a new original event.
Setup
Troubleshooting:
No Recent activity row:
- endpoint inactive
- wrong project
- event filter does not match
- monthly allowance exhausted
HTTP 404:
- receiver path does not exist
HTTP 401:
- wrong signing secret
- raw body changed before verification
- timestamp/signature invalid
HTTP 500:
- PulseGrid reached the receiver but receiver code failed
Connection error/timeout:
- DNS/TLS/firewall/receiver availability issue
Production task execution:
- Redis is the queue/broker
- Celery workers perform outbound HTTP
- Celery Beat schedules retry/cleanup work
- run only one Beat scheduler unless using a scheduler designed for multiple active instances
Code example
Quick status matrix
Pending -> waiting for execution
Processing -> worker claimed delivery
Retrying -> last attempt failed; another is scheduled
Succeeded -> receiver returned HTTP 2xx
Failed -> allowed attempts exhausted
Cancelled -> delivery was stopped
Production examples:
celery -A pulsegrid worker -l info
celery -A pulsegrid beat -l infoNotes
The manual Send test action is for endpoint connectivity. A real event test is still required to prove project/event matching.
Do not repeatedly retry irreversible work until the receiving application has delivery_id idempotency.