Debugging Webhooks
How to troubleshoot the Auto Pull webhook when a push to your Git repository does not show up in Entropy Data.
Debugging in Entropy Data
Start on the Git connection: open the Git connection dialog of the affected data contract or data product and compare the webhook URL in the Auto Sync Git to Entropy Data section with the URL configured in your Git provider — the URL is regenerated whenever the provider, host, repository, or branch of the connection changes, so an outdated URL in the provider is the most common cause of failing updates. Whether a pull actually succeeded is visible on the resource itself: the Git sync badge shows the Last synced time, which is updated after every successful pull, and the imported change appears in the resource's version history. Also verify that Git credentials are available at the organization or team level — webhook pulls run without a signed-in user, so user-level credentials are never used, and without an organization or team credential nothing is synced. If the file was pulled but the update still fails, the content itself may not pass validation (for example, invalid YAML); importing the file manually via the Git connection dialog surfaces those validation errors interactively. On self-hosted installations, administrators can additionally check the application logs, where failed webhook pulls are logged with the reason (missing credentials, unreachable repository, or import errors).
The webhook endpoint always responds with HTTP 200, even when the token is invalid or no matching connection exists — this prevents outsiders from probing for valid webhook URLs. A successful delivery in your Git provider's log therefore confirms only that the request reached Entropy Data, not that a pull succeeded. Use the Last synced time to verify the pull itself.
Debugging on the Sender Side
All four supported Git providers keep a delivery log for their webhooks, showing whether the push event was sent, what response was received, and — in most cases — offering a way to resend the request. If a delivery does not appear there at all, the webhook is not configured for push events on the branch you pushed to, or it was disabled by the provider after repeated failures.
GitHub
GitHub records webhook deliveries of the past 3 days. Go to your repository's Settings → Webhooks, select the webhook, and open the Recent Deliveries tab to inspect the full request and response of each delivery. A failed or missing delivery can be resent with Redeliver. See Viewing webhook deliveries and Redelivering webhooks.
GitLab
GitLab shows all requests of the last 2 days in the Recent events section: go to your project's Settings → Webhooks and edit the webhook to see them, including request and response bodies and headers. Use Resend Request to retry a delivery, or the Test dropdown to fire a synthetic push event without pushing a commit. GitLab also auto-disables webhooks that fail repeatedly — re-enable the webhook there after fixing the cause. See Troubleshooting webhooks.
Bitbucket Cloud
Bitbucket only records webhook requests after history has been enabled: go to Repository settings → Webhooks → View requests and select Enable history. From then on, each delivery is logged with its triggering event, timing, and outcome (HTTP status code, TIMEOUT, or NETWORK ERROR), and View details shows the full request. Note that deliveries made before enabling history are not shown. See Troubleshoot webhooks and Manage webhooks.
Azure DevOps
Azure DevOps webhooks are service hook subscriptions. Project settings → Service hooks summarizes the activity of the last 7 days per subscription and shows whether it is enabled, disabled, or restricted. Select a subscription and open History for the complete request and response data of each notification. Be aware that Azure DevOps disables or restricts subscriptions after repeated failures ("Disabled (due to failures)", "Enabled (restricted)") — after fixing the cause, re-enable the subscription so new events are delivered again. See Troubleshoot service hook integrations.