QTest notification subscriptions lack digest batching and quiet hours
0 reputation · 23 Jul 2023, 06:27 UTC
0 reputation · 23 Jul 2023, 06:27 UTC
Goal is to keep operational alerts useful without notification noise in QTest.
QTest offers per-user notification subscriptions for project events such as test runs, requirements changes and defects. Controls are managed through user profile and project subscription settings with opt-in per object type and role. Delivery is limited to objects the user can access.
There is no documented native support for quiet hours, digest batching or frequency throttling in the core product. Behavior can vary by edition and deployment. Alert relevance therefore depends on project membership, role permissions and manual subscription hygiene.
Decision point is whether to rely on native subscriptions for operational alerts or route critical alerts through an external integration to gain control over noise, batching and escalation.
Is native subscription support available for digest batching, quiet hours or frequency throttling for email alerts?
What is the effect of project membership and role permissions on cross-project alert visibility?
Is external integration required to control frequency and escalation of critical alerts?
32275 reputation · 23 Jul 2023, 07:46 UTC
Is native subscription support available for digest batching, quiet hours or frequency throttling for email alerts? No. QTest’s core product does not provide any UI or API parameters to batch notifications, schedule delivery windows, or throttle the frequency of email alerts. Each enabled event type is sent to the user immediately after the event occurs.
Alert visibility is strictly scoped to the projects a user is a member of and the roles that grant access to specific object types. If a user is not a member of a project, they will never receive notifications from that project, regardless of the subscription settings in other projects. Even within a project, a user’s role determines which event categories they can subscribe to; for example, a “Tester” role may receive defect updates, while a “Reporter” role may not.
Because the native system cannot batch or delay notifications, any requirement for quiet hours, digest emails, or escalation thresholds must be handled outside of QTest. Typical approaches include:
GET /api/v1/events) to poll for changes and then sending aggregated alerts through a custom script or a third‑party service such as Slack, Teams, or a ticketing system./api/v1/notifications (or the equivalent endpoint for your QTest edition).digestFrequency, quietHoursStart, or throttleLimit are present.Do you currently use a custom notification plugin or a third‑party integration (e.g., a Slack or Teams connector) that already implements digest or quiet‑hour logic? If so, that integration might obviate the need for an additional external workflow.
Use comments to ask for clarification. Post a solution as an answer.
32,275 reputation · 23 Jul 2023, 15:05 UTC
One clarification on native controls: QTest Enterprise 2026.x does expose a global Digest Frequency setting under User Profile → Email Notification Settings, which can aggregate events into daily or weekly batches. This is distinct from the per-project quiet hours or granular throttling discussed above, and it remains global rather than project-scoped. Role and membership restrictions still apply to which events appear in the digest. If your deployment predates this setting or runs custom plugins, the available options may differ, so verify the exact labels and behavior in your instance before relying on it for alert suppression. For true quiet-hour windows, external routing is still required.