Hi community! I have the new version of the DefectDojo Open Source (3.1.305) and tried to configure a webhook in django administration as an admin, but I'm not receiving any logs. Am I missing any other config? Where can I check logs or tasks related to this action?
Hi! A few things have to line up before notification webhooks fire — and the most likely cause is #1, which is probably also *why* you ended up in the Django admin: the UI page is hidden while the feature is off. *1. Turn the feature on:* Configuration → System Settings → "Enable Webhook notifications" (off by default). While it's off: • the "Notification Webhooks" menu entry is hidden and `/notifications/webhooks` returns a 404 • the *webhooks* column is hidden on the notification settings pages • nothing is ever sent, even though your endpoint exists in the DB — the dispatcher checks this flag *before* it looks at your endpoints, so you get no log line at all. Exactly the silence you're seeing. *2. Create (or re-save) the endpoint from the UI, not the Django admin:* Configuration → Notification Webhooks → Add (`/notifications/webhooks/add`). Saving there sends a test `ping` POST and only stores the endpoint if it returns 2xx, so you immediately see *why* it failed (DNS, TLS, 401, timeout…). It also resets `status` / `first_error` / `last_error` to a clean *Active*. The Django admin skips the ping entirely and `status` isn't editable there, so a broken endpoint just sits silently. If you already created one in admin, open it in the UI and hit save. *3. Subscribe events to the webhooks channel* — the most commonly missed step. On Configuration → Notifications (`/notifications/system` for system-level, `/notifications` for personal), every event has a checkbox per channel and the default is *alert only*. Tick *webhooks* for the events you want. *4. Match the endpoint's Owner to the notification scope:* • Owner *empty* = system webhook → receives system notifications, driven by the *system* notification settings page. • Owner *= a user* = personal webhook → receives only that user's personal notifications, driven by that user's own settings page. The endpoint lookup is an exact match on owner, so a system endpoint never receives personal notifications and vice versa. Setting yourself as owner but only configuring the system page (or the reverse) is a silent no-op. *5. Check the endpoint status* on the webhook list page. DefectDojo deactivates endpoints on failure: • 4xx or any exception → `inactive_permanent` immediately, no retries • 5xx / 429 / timeout → `inactive_tmp`, auto-retried after 60s by a Celery task, and permanently deactivated after ~24h of continuous failures The `note` field holds the last error. Editing + saving in the UI reactivates it (and re-pings). *Where to look for logs / tasks* The logger is `dojo.notifications.helper` (plus `dojo.notifications.tasks`). Set `DD_LOG_LEVEL=DEBUG` and watch *both* uwsgi and celeryworker — some events are dispatched to Celery (`async_create_notification`), others run inline in the request thread: ``` docker compose logs -f celeryworker uwsgi # k8s: kubectl logs -f deploy/defectdojo-celeryworker ``` Grep for these in order — the first one you *don't* see tells you which step above is missing: • `Sending Webhooks Notification` → flag is on *and* the event is subscribed to webhooks (steps 1 + 3 OK) • `URLs for Webhooks not configured: skipping system notification` → no endpoint matched the owner scope (step 4) • `URL for Webhook '<name>' is not active: …` → endpoint is deactivated (step 5) • `Sending webhook message to endpoint '<name>'` then `Message sent to endpoint '<name>' successfully.` → request actually made • `Error when sending message to Webhooks '<name>' (status: NNN): <body>` → your endpoint rejected it Celery also needs to be running for the retry/cleanup tasks (`webhook_reactivation`, `webhook_status_cleanup` in the beat schedule) — `docker compose exec celeryworker celery -A dojo inspect active` / `scheduled` is a quick sanity check. Failures that raise exceptions also show up as *Alerts* in the bell menu. Fastest end-to-end test: re-save the endpoint in the UI (that's the `ping`), then subscribe `product_type_added` to webhooks and create a product type. Per-event payloads are documented under Docs → Automation → API → Notification Webhooks: <docs.defectdojo.com/automation/api/notification_webhooks> One extra gotcha if you ever script the endpoint via the API instead of the UI: omitting `header_name` stores an empty string rather than null, and DefectDojo then tries to send a header with an empty name, which `requests` rejects — the endpoint gets permanently deactivated with `Exception: Invalid leading whitespace, reserved character(s), or return character(s) in header name: ''` in its note. Send `"header_name": null` or a real header name. (The UI and admin forms convert blank to null, so they're unaffected.)
It's working now, thank you !!
