Notifications is the alert layer of SITEY. It turns things that happen across the platform, a task assigned to you, a patch task that failed, a colleague tagging you in a vulnerability comment, a new critical finding, a critical finding that has been open too long, into a per-user inbox with an unread badge in the header, so work that needs a human does not sit waiting for someone to go looking for it.
The problem
A vulnerability platform without an alert layer is a pull system. Every status change is visible, but only to whoever remembers to open the right screen. In practice that means an analyst finds out a ticket was assigned to them at the next stand-up, a failed remediation task sits in failed for two days because the dashboard was never refreshed, and a critical vulnerability that landed at 02:00 is discovered the following afternoon.
Teams usually patch this with a shared mailbox and scanner emails. That fails in a predictable way: the mailbox receives every finding at the same priority, people build filters, the filters become mute rules, and the one message that mattered is archived unread along with the other four hundred. What is missing is not more email. It is a short, per-person list of the events that actually require that person to act, plus an unprompted nudge when a critical finding is aging past its deadline.
How it works
- Platform events write notification records
Notifications are not scraped after the fact, the modules that change state write them at the moment of the change. Creating a task, assigning a task, adding an assignee, or moving a task to in progress, completed, failed or blocked each produce a typed record for the affected user. On the vulnerability side, comment text is scanned for @username mentions and each matched user gets a mention notification carrying a preview of the comment; replying to a comment notifies the original author. Self-mentions and self-replies are skipped, so you are never notified about your own typing.
- An hourly job adds what nobody clicked
A background scheduler starts with the application and runs once an hour, in the opening minutes of the hour. It looks for two things and writes them to every active administrator account: critical findings that appeared in the last 24 hours and are still open, and critical findings older than seven days that are still open or in progress: the SLA warning, which includes the age in days.
LimitationThese two proactive alerts are addressed to administrator accounts, not to the analyst a finding happens to be assigned to, so plan your administrator roles accordingly.
Each one is deduplicated per vulnerability, per user and per type, so an aging critical does not produce a fresh alert every single hour. When the platform already has a learned remediation script that matches the new critical finding closely enough, the alert says so and carries that script’s recorded success rate, so the reader knows a fix already exists before they open the record.
- The bell and the inbox
The header bell keeps the most recent items and an unread count, refreshing every 30 seconds and again whenever the browser tab regains focus. The full Notifications page shows read and unread counts for the notifications it has loaded, a search box, all/unread/read filters, and a paginated list with relative timestamps and a colour band derived from the event type: a failed task reads as critical, a blocked task as high, an assignment as medium, a completion as low.
- A daily email digest for administrators
Once a day, at an hour you set (08:00 by default), an HTML summary is sent to every administrator account that has an email address: active findings, critical and high counts, what arrived in the last 24 hours, and a table of the findings themselves. When an AI model is configured, a written summary paragraph is generated and included. SMTP host, port, credentials and TLS for this digest are read from environment configuration at deployment, so it goes through your own mail relay and never through a vendor service.
LimitationDelivery is a single attempt: the platform logs a failed send rather than retrying it or queueing it, so treat your own relay and its logs as the source of truth for delivery.
- Everything stays scoped to one user
Every read, mark-as-read and delete is filtered by the signed-in user’s identity at the database query, including the bulk delete. One user cannot read, clear or tamper with another user’s inbox by guessing an identifier. When a vulnerability is deleted, its notifications go with it.
What you can do
See an unread count in the header on every screen, updated automatically while you work.
Filter the inbox to unread only, read only, or everything.
Search across notification titles, messages and categories.
Select several notifications at once and mark them read or delete them in one request.
Mark or delete a single notification inline, without leaving the list.
Get alerted when a task you own starts, completes, fails or is blocked.
Get alerted when someone tags you with @ in a vulnerability comment, or replies to your comment.
Have administrator accounts receive an unprompted SLA warning for criticals that have been open more than seven days, with the exact age.
Let administrators receive a daily email digest through your own SMTP relay.
Ask the security assistant to list your outstanding critical and SLA alerts instead of browsing for them.
Post a JSON payload to a URL of your choice from your own scripts, through an authenticated endpoint.
Who it is for
| Role | What they get from it |
|---|---|
| SOC analyst | Is pulled into a discussion the moment a mention or reply names them, and sees every status change on the tasks they own |
| System administrator / patch owner | Sees a failed or blocked patch task the same hour, not at the next review |
| Team lead | Watches assignment and completion traffic without asking for status in chat |
| CISO / security manager | Gets the daily digest by email on an administrator account: what is open, what is critical, what arrived overnight |
| Compliance officer | Uses the SLA warnings raised on administrator accounts as evidence that overdue criticals were surfaced, and when |
Why it matters
The platform’s promise is closing critical vulnerabilities in 72 hours. That budget is spent almost entirely in the gaps between automated steps, the hours a finding waits for a person to notice that it is their turn. Cutting a single overnight wait out of the chain is worth more than making any individual automated phase faster, because the automated phases already run in minutes.
The SLA warning matters for a different reason. Every other alert here is a reaction to something a human just did.
The seven-day warning is the only signal that fires precisely because nobody did anything, which is exactly the failure mode a vulnerability programme has to catch.
It is also the point at which a missed deadline becomes a documented, timestamped event rather than something discovered during an audit.
Works with
- Task management, most notifications originate here: creation, assignment and every status change
- Team workflow, comment mentions and replies on vulnerability records
- AI daily summary, the content of the administrator email digest
- Security assistant, query your outstanding critical and SLA alerts in conversation
Frequently asked questions
Does every notification arrive as an email?
No. Event notifications, tasks, mentions, replies, new criticals, SLA warnings, are delivered in the application: the header bell and the Notifications page. Email is used for one thing, the scheduled daily digest to administrators. Routine events are not mailed individually by design, which is what keeps the alerts readable.
Is delivery instant?
Notifications are written the moment the event happens. The browser picks them up on a 30-second refresh cycle and immediately when you return to the tab, so a new alert appears within about half a minute rather than instantly.
Can it post to Slack or Microsoft Teams?
There is no packaged Slack or Teams connector. What exists is a generic authenticated endpoint that posts a JSON payload you supply to a URL you supply, with a five second timeout and no retry, which is enough to wire up an incoming webhook or an internal relay yourself. If a native chat integration is a requirement for your team, treat it as integration work on your side.
Can one person see another person’s notifications?
No. Every query, listing, marking read, deleting, bulk deleting, is constrained to the signed-in account at the database level, so a notification identifier belonging to someone else simply returns nothing. Deleting a vulnerability also removes the notifications attached to it.
Notifications is included in every SITEY deployment; there is no separate alerting tier and no per-seat charge for it. Like the rest of the platform it runs inside your own infrastructure, sends the daily digest through your own mail relay, and keeps every alert in your database. See pricing for what a full deployment costs.