Destinations are used to deliver alerts to your team.

When a policy fails or a rule triggers, an alert is generated with basic context and sent to the configured destination.

Alerts are routed based on severity and a single alert can dispatch to multiple destinations simultaneously, such as creating a Jira ticket, sending an email, and creating a PagerDuty Incident.

Destinations can also be overridden on a per-rule or per-policy basis.

AWS destinations require IAM configurations to grant permissions for Panther to publish notifications

Supported Destinations

Creating a New Destination

To create a destination, navigate to Settings > Destinations and select Add Destination.

You will then be prompted to select a destination type.

Multiple destinations of the same type may be configured, such as several Slack channels or email addresses. This allows for fine grained control of destination routing.

Next, add a Display Name to distinguish the destination from others in the Panther UI and optionally select the associated severities for this destination.

Each destination type will have specific configuration options based on the system's API. See the destination specific setup instructions in the following pages for more details.

Finally, click the Add Destination button to save the configuration. You will be prompted to optionally send a test alert to check if everything was set up correctly.

Let's send a test to make sure everything is working as expected.

If successful, click Finish Setup. You are now ready to receive alerts!

Modifying or Deleting Destinations

An existing destination may be modified or deleted by selecting the triple dot button. From here, you can modify the display name, the severities, and the specific configurations. Alternatively, you can also delete the destination.

Workflow Automation

You may use any of the above destinations for many existing workflows. However, our Custom Webhook is available to provide additional flexibility for any workflow.

Alert Schema

A Custom Webhook will deliver an alert with the following shape:

"id": string,
"createdAt": AWSDateTime,
"severity": string,
"type": string,
"link": string,
"title": string,
"name": string,
"alertId": string,
"description": string,
"runbook": string,
"tags": [string],
"version": string

The AWSDateTime scalar type represents a valid extended ISO 8601 DateTime string. In other words, this scalar type accepts datetime strings of the form YYYY-MM-DDThh:mm:ss.sssZ. The field after the seconds field is a nanoseconds field. It can accept between 1 and 9 digits. The seconds and nanoseconds fields are optional (the seconds field must be specified if the nanoseconds field is to be used). The time zone offset is compulsory for this scalar. The time zone offset must either be Z (representing the UTC time zone) or be in the format ±hh:mm:ss. The seconds field in the timezone offset will be considered valid even though it is not part of the ISO 8601 standard.

Example JSON payload:

"id": "AllLogs.IPMonitoring",
"createdAt": "2020-10-13T03:35:24Z",
"severity": "INFO",
"type": "RULE",
"link": "",
"title": "New Alert: Suspicious traffic detected from []",
"name": "Monitor Suspicious IPs",
"alertId": "b90c19e66e160e194a5b3b94ec27fb7c",
"description": "This rule alerts on any activity outside of our IP address whitelist",
"runbook": "",
"tags": [
"Network Monitoring",
"Threat Intel"
"version": "CJm9PiaXV0q8U0JhoFmE6L21ou7e5Ek0"