TigerGate can push scan results, quality-gate failures, critical findings, and compliance and runtime events to the tools your team already uses. Notification channels are configured per organization, and delivery is retried automatically on failure.
Configure channels under Integrations → Notifications (the Notifications & Issue Tracker page).
Notification channels
On the Notification Channels tab, choose Add Channel, pick a type, give it a name, and enter its configuration. Each configured channel has Edit, Test, and remove actions.
| Channel | Configuration |
|---|
| Slack | Incoming webhook URL, plus an optional bot token |
| Microsoft Teams | Incoming webhook URL |
| Email | Recipient list, plus optional SMTP host / port / username / password (leave the SMTP fields blank to use the platform default server) |
| PagerDuty | API key, plus an optional Events API v2 routing key (used for critical incident paging) |
| Custom Webhook | Endpoint URL, plus an optional signing secret |
If you set a signing secret on a Custom Webhook, TigerGate adds an X-TigerGate-Signature header to each request so you can confirm the payload came from TigerGate.
Issue tracker
The Issue Tracker tab connects a ticketing system so your team can create tickets directly from security findings.
| Provider | Configuration |
|---|
| Jira | API token, site domain (<domain>.atlassian.net), project key, default issue type |
| GitHub Issues | Personal access token (or the connected GitHub App installation), repository, default issue type |
| Linear | API key, team ID, optional default issue type |
Events
Once at least one channel is configured, TigerGate delivers alerts for:
| Event | When |
|---|
| Scan results | A scan finishes |
| Quality-gate failures | A scan trips a configured quality gate |
| Critical findings | A new critical finding is detected |
| Compliance report | A scheduled compliance report is generated |
| Compliance violation | A control moves into a failing / violation state |
| Control status change | A control’s pass/fail status changes |
| Agent status | A runtime agent goes online or offline |
Delivery and retries
Failed deliveries are retried automatically up to three times with exponential backoff — starting at roughly one second, doubling each attempt, and capped at 30 seconds, with jitter. A background sweep also re-attempts recently failed sends.
Test a channel
Every configured channel has a Test button that sends a connection test to the destination, so you can confirm the webhook is reachable, the credentials are valid, or the email passes your filters before real alerts start flowing. 
