I have searched for all existing open AND closed issues and discussions for similar requests. I have found none that is comparable to my request.
Verify Feature Scope
I have read through and understood the scope definition for feature requests in the Issues section. I believe my feature request meets the definition and belongs in the Issues section instead of the Discussions.
The notification is only sent if you are not actively using the WebUI. If you have the tab open and focused, the webhook will not be triggered, preventing unnecessary notifications.
But no matter what I try, the webhook is never triggered. Might be related to my particular setup with Consul/Envoy that has much longer request/idle timeouts to accommodate local LLM generations. OWUI websocket connections don't time out for hours.
Desired Solution you'd like
Please add an option to always trigger the user notification webhook
Alternatives Considered
Polling the API or postgres database for updates is not great from traffic & security perspective.
Additional Context
No response
Originally created by @Material-Scientist on GitHub (May 15, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/24750
### Check Existing Issues
- [x] I have searched for all existing **open AND closed** issues and discussions for similar requests. I have found none that is comparable to my request.
### Verify Feature Scope
- [x] I have read through and understood the scope definition for feature requests in the Issues section. I believe my feature request meets the definition and belongs in the Issues section instead of the Discussions.
### Problem Description
See discussion: https://github.com/open-webui/open-webui/discussions/19057#discussioncomment-16928130
According to the [docs]:
> The notification is only sent if you are not actively using the WebUI. If you have the tab open and focused, the webhook will not be triggered, preventing unnecessary notifications.
But no matter what I try, the webhook is never triggered. Might be related to my particular setup with Consul/Envoy that has much longer request/idle timeouts to accommodate local LLM generations. OWUI websocket connections don't time out for hours.
### Desired Solution you'd like
Please add an option to always trigger the user notification webhook
### Alternatives Considered
Polling the API or postgres database for updates is not great from traffic & security perspective.
### Additional Context
_No response_
@owui-terminator[bot] commented on GitHub (May 15, 2026):
🔍Related Issues Found
I found some existing issues that might be related. Please check if any of these are duplicates or contain helpful solutions:
🟢#24589issue: Calendar notifications and webhooks do not trigger when reminder is set to "At time of event" This is also about notifications/webhooks not firing at a specific trigger condition. While it concerns calendar reminders rather than the user notification webhook, it suggests the same notification path may be skipped under certain timing/state conditions. by onikyannn · bug
🟣#24377issue: LDAP signup does not trigger WEBHOOK_URL notification (signup webhook only fires for password and OAuth signups) This issue is directly about WEBHOOK_URL notifications not being triggered for one account-creation path. It is the closest match to a webhook-not-triggered bug and may share the same webhook delivery logic. by JulienDelRio · bug
🟢#1240feat: additional webhook events This is the umbrella feature request for expanding webhook event coverage. The new issue is also a webhook-related feature request, so this is relevant as an existing broader request in the same area. by tjbck · enhancement, good first issue, help wanted
🟣#1174feat: webhook This is the original webhook feature issue that #1240 extends. It is the foundational webhook request and likely the parent context for changes to webhook behavior. by tjbck · enhancement, core
💡 If your issue is a duplicate, please close it and add any additional details to the existing issue instead.
This comment was generated automatically. React with 👍 if helpful, 👎 if not.
<!-- gh-comment-id:4458394599 -->
@owui-terminator[bot] commented on GitHub (May 15, 2026):
<!-- terminator-bot:related-issues-reply -->
🔍 **Related Issues Found**
I found some existing issues that might be related. Please check if any of these are duplicates or contain helpful solutions:
1. 🟢 [#24589](https://github.com/open-webui/open-webui/issues/24589) **issue: Calendar notifications and webhooks do not trigger when reminder is set to "At time of event"**
*This is also about notifications/webhooks not firing at a specific trigger condition. While it concerns calendar reminders rather than the user notification webhook, it suggests the same notification path may be skipped under certain timing/state conditions.*
*by onikyannn · `bug`*
2. 🟣 [#24377](https://github.com/open-webui/open-webui/issues/24377) **issue: LDAP signup does not trigger WEBHOOK_URL notification (signup webhook only fires for password and OAuth signups)**
*This issue is directly about `WEBHOOK_URL` notifications not being triggered for one account-creation path. It is the closest match to a webhook-not-triggered bug and may share the same webhook delivery logic.*
*by JulienDelRio · `bug`*
3. 🟢 [#1240](https://github.com/open-webui/open-webui/issues/1240) **feat: additional webhook events**
*This is the umbrella feature request for expanding webhook event coverage. The new issue is also a webhook-related feature request, so this is relevant as an existing broader request in the same area.*
*by tjbck · `enhancement`, `good first issue`, `help wanted`*
4. 🟣 [#1174](https://github.com/open-webui/open-webui/issues/1174) **feat: webhook**
*This is the original webhook feature issue that `#1240` extends. It is the foundational webhook request and likely the parent context for changes to webhook behavior.*
*by tjbck · `enhancement`, `core`*
---
💡 If your issue is a duplicate, please close it and add any additional details to the existing issue instead.
*This comment was generated automatically.* React with 👍 if helpful, 👎 if not.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @Material-Scientist on GitHub (May 15, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/24750
Check Existing Issues
Verify Feature Scope
Problem Description
See discussion: https://github.com/open-webui/open-webui/discussions/19057#discussioncomment-16928130
According to the [docs]:
But no matter what I try, the webhook is never triggered. Might be related to my particular setup with Consul/Envoy that has much longer request/idle timeouts to accommodate local LLM generations. OWUI websocket connections don't time out for hours.
Desired Solution you'd like
Please add an option to always trigger the user notification webhook
Alternatives Considered
Polling the API or postgres database for updates is not great from traffic & security perspective.
Additional Context
No response
@owui-terminator[bot] commented on GitHub (May 15, 2026):
🔍 Related Issues Found
I found some existing issues that might be related. Please check if any of these are duplicates or contain helpful solutions:
🟢 #24589 issue: Calendar notifications and webhooks do not trigger when reminder is set to "At time of event"
This is also about notifications/webhooks not firing at a specific trigger condition. While it concerns calendar reminders rather than the user notification webhook, it suggests the same notification path may be skipped under certain timing/state conditions.
by onikyannn ·
bug🟣 #24377 issue: LDAP signup does not trigger WEBHOOK_URL notification (signup webhook only fires for password and OAuth signups)
This issue is directly about
WEBHOOK_URLnotifications not being triggered for one account-creation path. It is the closest match to a webhook-not-triggered bug and may share the same webhook delivery logic.by JulienDelRio ·
bug🟢 #1240 feat: additional webhook events
This is the umbrella feature request for expanding webhook event coverage. The new issue is also a webhook-related feature request, so this is relevant as an existing broader request in the same area.
by tjbck ·
enhancement,good first issue,help wanted🟣 #1174 feat: webhook
This is the original webhook feature issue that
#1240extends. It is the foundational webhook request and likely the parent context for changes to webhook behavior.by tjbck ·
enhancement,core💡 If your issue is a duplicate, please close it and add any additional details to the existing issue instead.
This comment was generated automatically. React with 👍 if helpful, 👎 if not.