Webhook delivery log fields for safe response debugging
Use consistent fields for each delivery attempt. Record the final status code and approved response metadata. Exclude URLs, request headers, authorization, payloads, and raw response content.
- 1
Delivery finishes
Emit once after success or permanent retry exhaustion, not once per log line.
- 2
Use consistent fields
Map source fields such as attempt_number to attempt_count, then keep status_code, response_body_bytes, and an allowlisted content type instead of raw response_body.
- 3
Secrets stay out
Never store request_headers, authorization values, customer URLs, or webhook payloads.
- 4
Measure recovery
Compare permanent failures, recurring status codes, and recovery after retries by destination type.
Grain
One final outcome per logical webhook delivery.
Owner
Webhook delivery worker
Emit when
After success or permanent retry exhaustion.
Field contract
Field types and data to exclude
Keep field names and types stable once production queries depend on them. Document optional fields and add them only when they answer a specific question.
| Field | Type | Required | Privacy | Meaning |
|---|---|---|---|---|
| timestamp_utc | timestamp | yes | non-sensitive | UTC time when the operation finishes. |
| event_id | string | yes | non-sensitive | Stable unique identifier used for deduplication. |
| release | string | yes | non-sensitive | Application or service version that emitted the event. |
| account_id | string | yes | pseudonymous | Stable internal account identifier, never an email or name. |
| delivery_id | string | yes | pseudonymous | Stable logical delivery identifier. |
| destination_type | string | yes | non-sensitive | Bounded integration category, not a destination URL. |
| attempt_count | number | yes | non-sensitive | Attempts through the terminal outcome. |
| status_code | number | no | non-sensitive | Final HTTP status when a response exists. |
| response_body_bytes | number | no | non-sensitive | Final response-body size in bytes. Store the size instead of the response body. |
| response_content_type | string | no | review | Allowlisted response media type such as application/json; never copy unrestricted response headers. |
| status | string | yes | non-sensitive | Delivered or permanently failed. |
Synthetic JSON event
{
"timestamp_utc": "2026-07-28T14:29:08Z",
"event_id": "evt_webhook_01",
"account_id": "acct_8f31",
"release": "2026.07.2",
"delivery_id": "delivery_09cc",
"destination_type": "slack",
"attempt_count": 1,
"status_code": 200,
"response_body_bytes": 27,
"response_content_type": "application/json",
"status": "delivered"
}Privacy review
Review identifiers before ingestion
This example uses synthetic identifiers. Pseudonymous values can still be personal data, and review fields can expose business or provider context. Apply your own consent, retention, access, residency, and deletion requirements.
account_id: pseudonymousdelivery_id: pseudonymousresponse_content_type: review
Validation checklist
Test the schema before building a dashboard
- Send one known webhook_delivery_completed fixture after the documented outcome boundary.
- Verify all 8 required fields arrive with the documented types.
- Retry the same event identifier and confirm the chosen deduplication behavior.
- Send a controlled failure or alternate outcome when the workflow supports one.
- Run the related SQL over a fixed window and reconcile the result to the fixture.
Common mistakes
Record one result per row
- Emitting webhook_delivery_completed before webhook delivery worker knows the final outcome.
- Mixing different kinds of results in one table, which makes counts and rates ambiguous.
- Replacing controlled categories with raw URLs, payloads, prompts, or error text.
- Changing a field type in place after saved queries and dashboards depend on it.
- Adding identifiers without a documented investigation, access, and retention need.
Use the contract
Query the event and set up monitoring
Related contracts
Send a test event before production traffic
Create a free API key, send the synthetic event, and inspect the inferred table before connecting a live workflow.