Vexta Notifications: Getting New Findings into Slack, Discord or Email

Vulnerability scan notifications are alerts pushed out automatically when a scan finds something new, instead of requiring someone to log in and check. Vexta is VITI Security's agentless, AI-augmented vulnerability scanner and pentest platform, and it can send those alerts to eight channel types, including Slack, Discord, Telegram, Pushover, email, Google Chat, Microsoft Teams and custom webhooks, with every channel supporting multiple separate instances.

Which channels can Vexta notify?

Eight channel types are supported: Slack, Discord, Telegram, Pushover, email over SMTP, Google Chat, Microsoft Teams and custom webhooks. Every one of them supports multiple instances, so a single Vexta install is not limited to one Slack workspace or one email address.

That multi-instance support is the detail that makes it useful past a solo setup. A consultancy running scans for several clients can route each client's findings to that client's own Slack channel or webhook, while a separate internal channel gets everything, without needing separate Vexta instances to keep the streams apart.

The channel mix also spans how different people actually want to be reached. A developer team already living in Microsoft Teams or Google Chat gets findings where they already look for work items. A solo hunter running recon against several bug bounty programs might prefer Telegram or Pushover on a phone. An internal security team wiring Vexta into a SIEM or a ticketing system reaches for the custom webhook instead of any of the chat-app options, since a webhook is the one channel built to be read by another system rather than a person.

How do the notification templates work?

All channels support {{data}} template placeholders, so a message body is not hardcoded to one fixed sentence. A Slack alert can be formatted differently from a webhook payload feeding some other internal tool, while both are pulling from the same underlying finding data.

That flexibility matters when a raw webhook is feeding an internal system rather than being read by a human. A ticketing system or a custom dashboard expecting a specific payload shape can get exactly that, built from the same template mechanism a human-readable Slack message uses.

Why does a hunter or a security lead want push notifications instead of checking a dashboard?

On a bug bounty program with recon running continuously, or an internal AppSec team watching a moving codebase, the value of a finding often depends on being early. A critical finding that sits unread in a dashboard for two days because nobody happened to log in is a finding that might already be discovered by someone else, or a risk that sat unpatched two extra days for no reason.

Pushover and mobile-friendly channels like Slack or Telegram close that gap for anyone away from their desk. A security lead who gets pinged the moment a critical severity finding lands does not have to build the habit of checking a dashboard on a schedule; the notification does that instead.

This matters even more once scheduled scans are involved. A recurring scan that runs overnight or over a weekend is not useful if the results just sit in the dashboard until someone happens to log back in on Monday. A notification tied to that same schedule turns an unattended scan into something closer to a standing alert system, where the person who needs to know finds out within minutes of a new critical or high severity finding, not days later.

Setting up notifications without overloading a channel

Because every channel supports multiple instances and templated content, it is worth being deliberate about what triggers a notification rather than routing every single finding, including low-severity noise, to a channel someone is expected to read in real time. A separate low-priority channel or a filtered webhook for anything below a certain severity keeps the high-signal channel actually high-signal.

Notification setup lives alongside the rest of the scanner's configuration on the dashboard's /configuration page, next to API keys and hunting settings, so it is one place to review everything wired up to an instance rather than settings scattered across separate screens.

A practical starting point is to route only critical and high severity findings to whichever channel your team actually reads in real time, and let medium and low severity results wait for the dashboard review a hunter does anyway once a scan finishes. That split keeps a phone buzzing for the findings that are actually time-sensitive, and stops the same channel from becoming something people learn to mute.

Key takeaways