Review team notifications and delivery problems
Use the team's notification history to understand an alert and take the appropriate action. The in-app record, an email send and an SMS delivery are different evidence sources. Marking an alert read acknowledges the record; it does not resolve billing, usage, security or delivery problems.
Availability: select the team, then open Settings → Notifications. This tab is not exclusively for Team Admins. Team viewers can access notifications permitted to them: Team Admins and platform-wide readers can see the team's broader history; other team members/viewers are limited to system notifications and their own password-expiry entries.
Who sees which notifications
See Access and teams when a teammate sees a different list. Do not broaden access solely to compare alerts. Read actions are allowed through the notification service's self-service path and operate on the visible records.
Subscription actions also depend on access to subscription settings and their feature availability. A notification can exist even when its subscription action is not available to your role. Ask the billing/team administrator to handle that action rather than treating the hidden link as a missing alert.
Open notifications from the header
Select the intended team, then choose the notification bell in the header to open Settings → Notifications. Its badge is the unread count for that team and your allowed notification scope, refreshed periodically (the count query requests a refresh every 30 seconds). No selected team means the count query does not run; an empty badge is not proof there are no notifications across the platform.
The bell opens the history page; it does not acknowledge every alert or send a message. Follow the review/read actions below. Because read state is shared on stored notification records, another authorized reader can change what appears in your Unread list. Browser theme/language preferences do not configure alert recipients, email delivery or an individual notification opt-out.
Review and acknowledge an alert
- Confirm the selected team and open All first. The history is ordered newest first; use Load more when older records are available.
- Read the title, message, resource, creation time and any threshold percentage. Distinguish a usage threshold from a subscription/payment or account event.
- Follow the provided action when relevant and permitted. Usage/overage alerts can offer subscription and dashboard links; verify the current state there instead of assuming the older alert describes today's usage.
- Use the read action after review, or Mark all as read for the visible unread scope. Unread filters out records already acknowledged.
| Card information | How to use it |
|---|---|
| Title and message | The recorded reason for the notification; preserve the specific event when escalating. |
| Resource | Helps distinguish usage/overage, subscription, billing, account, password-expiry or system context. An SMS resource can describe SMS usage; it does not prove an SMS message was sent. |
| Threshold percentage, when present | Threshold attached to this record, not an independently refreshed usage measurement. |
| Created time | Correlate with the originating event and the period being investigated. |
| Read/unread | Acknowledgment state on the notification record. It is not a private per-user read receipt. |
| Action link, when present | Follow-up action relevant to the alert and your access; not every notification has one. |
The resource identifiers include MINUTES, TOKENS and SMS for ordinary usage; OVERAGE_MINUTES, OVERAGE_TOKENS, OVERAGE_SMS and OVERAGE_TOTAL for overage; and SUBSCRIPTION, BILLING, ACCOUNT, LEGAL, SYSTEM and PASSWORD_EXPIRY for those event categories. A resource identifies the notification's subject, not the delivery transport or the severity of a runtime log.
Read status is shared on the stored record. Marking a team notification read can therefore remove it from another eligible reader's Unread view. If an expected alert disappears there, check All before concluding it was deleted. The page is a history/acknowledgment view, not a notification composer or scheduler.
Separate inbox records, email and SMS
| Surface | What its success establishes | What remains to check |
|---|---|---|
| In-app notification | A record exists for the team and is visible to you. | Whether the underlying problem was resolved and whether any separate message was sent. |
| Queued email request | The request was accepted into the configured sending path. | Worker execution, transport result and actual recipient delivery. |
| Configured notification email | The enabled notification type and recipient resolution allowed an email attempt. | Transport outcome; recipient receipt is not proved by the in-app card. |
| SMS send result | Depending on its state, it may show blocked, rejected or provider-accepted processing. | Provider acceptance is not the same as delivery to the handset. |
The platform administrator manages notification types separately from this team inbox. Configured notification email needs an existing enabled type, valid recipients and a working email transport. Recipient entries may be fixed addresses or values supplied for that event; a valid template does not ensure the event supplied every expected value.
The dedicated notification worker deliberately skips a disabled type. Other reported send failures enter its retry/dead-letter path. Direct email jobs and other callers have their own paths, so do not assume one global notification switch or one retry count controls every message.
SMS delivery additionally depends on SMS enablement, an allowed quota and a configured provider. The worker can return a blocked result for quota or a permanent rejection without treating it as successful sending. It retains provider-acceptance checkpoints to resume accounting after certain failures; this is not a universal exactly-once delivery guarantee.
Diagnose a missing or repeated notification
Start with the selected team, visibility and All/Unread filter. Record the approximate event time and resource. Ask the responsible administrator whether the event should produce an in-app record, email, SMS, or more than one of these; none is automatic evidence for another.
For queued delivery, give the operator the job ID when available and ask for the job's status, attempt count, last error and next-attempt time. Worker retry scheduling uses each job's attempt/delay settings; exhausted attempts become DEAD. A planned time or a completed processing step alone is not proof that a person received the message.
For email, check type enablement, recipient resolution and transport errors. For SMS, distinguish feature-disabled, quota-blocked, permanent provider rejection and retryable transport failure. Do not repeatedly resubmit an uncertain send: it may already have reached the provider. Have the operator inspect the stored result/checkpoint first.
For missing password or security alerts, use the authorized account-support procedure. Do not forward reset links, credentials or recipient details into a general support report. For runtime correlation, use Logs and diagnostics.
For password-age reminders, distinguish the authenticated change-password link from token recovery. If a message is missing, use background-job diagnosis to separate enqueueing, worker completion and delivery.
For missing email, use Configure and verify email delivery to separate notification rules, the sending process and SMTP/SES transport. The inbox does not configure those transports.
Verify the outcome
- Reopen All for the intended team and confirm the alert you reviewed is listed with the expected resource and time.
- Confirm the responsible owner has checked the underlying billing, usage, account or system state.
- For a delivery question, confirm that any claim is backed by a send attempt (job status or SMS result) or an explicit reason no attempt was made. Marking the card read is not this evidence.
Related
- Access and teams — to check team selection and role scope when two people see different lists.
- Subscription and usage — to act on usage, overage or payment alerts.
- Background jobs — to trace notification enqueueing, retries and worker failures.
- Logs and diagnostics — to correlate an alert time with service logs.