Skip to main content

Monitoring webhook health

Key metrics to track

Monitor these metrics to ensure your webhook integration is healthy:

Setting up monitoring

Application-level monitoring

Logging best practices

Structured logging

Use structured logging to make webhook events searchable and analyzable:

Log aggregation

Send logs to a centralized logging service for analysis:

Debugging webhook issues

Common issues and solutions

Symptoms: No requests arriving at your endpointDebugging steps:
  1. Verify the webhook is enabled in ButterCMS settings
  2. Check the endpoint URL is correct and publicly accessible
  3. Test the endpoint with curl: curl -X POST https://your-endpoint.com/webhooks/buttercms
  4. Check firewall rules and security groups
  5. For local development, ensure ngrok/tunnel is running
Solution: Usually a configuration or network issue. Verify URL accessibility from outside your network.
Symptoms: ButterCMS indicates delivery failureDebugging steps:
  1. Check server logs for incoming requests
  2. Verify your endpoint returns 2xx status codes
  3. Ensure response time is under 30 seconds
  4. Check for SSL certificate issues
Solution: Review server logs to identify the specific error. Common causes: slow processing, exceptions, SSL issues.
Symptoms: Request received but actions not happeningDebugging steps:
  1. Log the full webhook payload
  2. Verify payload structure matches expectations
  3. Check event type handling in your switch/if statements
  4. Verify downstream services (cache, database) are accessible
Solution: Add detailed logging at each processing step to identify where the failure occurs.
Symptoms: Same webhook processed multiple timesDebugging steps:
  1. Check if your endpoint is responding too slowly (causing retries)
  2. Look for timeout errors in logs
  3. Verify idempotency implementation
Solution: Implement idempotency using event IDs or timestamps. Speed up response time.
Symptoms: Webhook processes but content remains staleDebugging steps:
  1. Verify cache invalidation is actually running
  2. Check CDN cache headers and TTLs
  3. Confirm the correct cache keys are being cleared
  4. Test by manually clearing cache
Solution: Add logging to cache invalidation. Verify CDN is receiving purge requests.

Debug mode

Enable debug mode during development to see full payload details:

Testing webhooks locally

Using ngrok

Expose your local server to receive webhooks during development:
ngrok provides a public URL like https://abc123.ngrok.io that forwards to your local server. Pipedream dashboard showing webhook request

Using webhook testing services

For quick testing without setting up your own endpoint: Webhook.site
RequestBin

Simulating webhooks

Test your handler with simulated webhook payloads:

Alerting

Setting up alerts

Configure alerts to notify you of webhook issues:

PagerDuty Integration

Slack Notifications

Alert conditions

Set up alerts for these conditions:

Dashboard examples

Grafana dashboard

Create a dashboard to visualize webhook health:

Key dashboard panels

  1. Real-time success rate - Shows current webhook health
  2. Latency percentiles - P50, P95, P99 processing times
  3. Events by type - Distribution of webhook events
  4. Error breakdown - Categorized errors for debugging
  5. Processing queue depth - For async processing systems

Troubleshooting checklist

Use this checklist when debugging webhook issues:

Pre-flight checks

  • Webhook enabled in ButterCMS settings
  • Correct endpoint URL configured
  • Correct event types selected
  • Endpoint is publicly accessible
  • SSL certificate is valid (for HTTPS)

Endpoint checks

  • Server is running and healthy
  • Endpoint accepts POST requests
  • Endpoint returns 2xx status codes
  • Response time is under 30 seconds
  • Authentication is correctly configured

Processing checks

  • Payload is being parsed correctly
  • Event type is being handled
  • Downstream services are accessible
  • No exceptions being thrown
  • Idempotency is implemented

Infrastructure checks

  • Firewall allows inbound traffic
  • Load balancer is routing correctly
  • DNS is resolving correctly
  • No rate limiting blocking requests
  • Sufficient server resources