scanner
  • About Scanner
  • When to use it
  • Architecture
  • Getting Started
  • Playground Guide
    • Overview
    • Part 1: Search and Analysis
    • Part 2: Detection Rules
    • Wrapping Up
  • Log Data Sources
    • Overview
    • List
      • AWS
        • AWS Aurora
        • AWS CloudTrail
        • AWS CloudWatch
        • AWS ECS
        • AWS EKS
        • AWS GuardDuty
        • AWS Lambda
        • AWS Route53 Resolver
        • AWS VPC Flow
        • AWS VPC Transit Gateway Flow
        • AWS WAF
      • Cloudflare
        • Audit Logs
        • Firewall Events
        • HTTP Requests
        • Other Datasets
      • Crowdstrike
      • Custom via Fluentd
      • Fastly
      • GitHub
      • Jamf
      • Lacework
      • Osquery
      • OSSEC
      • Sophos
      • Sublime Security
      • Suricata
      • Syslog
      • Teleport
      • Windows Defender
      • Windows Sysmon
      • Zeek
  • Indexing Your Logs in S3
    • Linking AWS Accounts
      • Manual setup
        • AWS CloudShell
      • Infra-as-code
        • AWS CloudFormation
        • Terraform
        • Pulumi
    • Creating S3 Import Rules
      • Configuration - Basic
      • Configuration - Optional Transformations
      • Previewing Imports
      • Regular Expressions in Import Rules
  • Using Scanner
    • Query Syntax
    • Aggregation Functions
      • avg()
      • count()
      • countdistinct()
      • eval()
      • groupbycount()
      • max()
      • min()
      • percentile()
      • rename()
      • stats()
      • sum()
      • table()
      • var()
      • where()
    • Detection Rules
      • Event Sinks
      • Out-of-the-Box Detection Rules
      • MITRE Tags
    • API
      • Ad hoc queries
      • Detection Rules
      • Event Sinks
      • Validating YAML files
    • Built-in Indexes
      • _audit
    • Role-Based Access Control (RBAC)
    • Beta features
      • Scanner for Splunk
        • Getting Started
        • Using Scanner Search Commands
        • Dashboards
        • Creating Custom Content in Splunk Security Essentials
      • Scanner for Grafana
        • Getting Started
      • Jupyter Notebooks
        • Getting Started with Jupyter Notebooks
        • Scanner Notebooks on Github
      • Detection Rules as Code
        • Getting Started
        • Writing Detection Rules
        • CLI
        • Managing Synced Detection Rules
      • Detection Alert Formatting
        • Customizing PagerDuty Alerts
      • Scalar Functions and Operators
        • coalesce()
        • if()
        • arr.join()
        • math.abs()
        • math.round()
        • str.uriencode()
  • Single Sign On (SSO)
    • Overview
    • Okta
      • Okta Workforce
      • SAML
  • Self-Hosted Scanner
    • Overview
Powered by GitBook
On this page
  • Alert object
  • Templating

Was this helpful?

  1. Using Scanner
  2. Beta features

Detection Alert Formatting

Custom formatting for detection alerts

PreviousManaging Synced Detection RulesNextCustomizing PagerDuty Alerts

Last updated 5 days ago

Was this helpful?

Detection alert formatting allows teams to customize the content in detection alerts that are sent to event sinks, like Slack and webhooks.

You can add custom formatting by going to the create/edit detection rule page and going to the Format Alert section. This feature is also support in Detections as Code, see for more information.

In Information, you can add section headers and text for the alert body. In the example below, there is a section titled Description and the section text includes the description of the detection rule.

In Actions, you can add action names and URLs, such as a runbook link for the alert. Actions will appear as buttons in Slack and as links in Markdown. If the value is an invalid URL or not a URL, the key/value will appear as text in the alert, rather than as a button or link.

The Preview button will allow you to view the formatting in Slack, Markdown, and JSON.

Note that some event sinks may have limits on the length of text that may be sent; in that case, Scanner will truncate the alert text to fit.

Alert object

The @alert object represents a detection alert and contains the following fields:

Field
Type
Description

id

string

Unique identifier for the detection alert

detection_rule_id

string

Unique identifier for the detection rule that triggered the alert

tenant_id

string

Unique identifier for the tenant

severity_id

number

name

string

Name of the detection rule

description

string

Description of the detection rule

query_text

string

Query for the detection rule

detected_in_time_range.start

string

Start of the detection time range

detected_in_time_range.end

string

End of the detection time range

timestamp

string

The time the detection was triggered. Note that this can be outside of the detection time range.

tags[i]

string

The i-1th tag for the detection rule, e.g. tags[0]will return the first tag for the detection rule.

results_table.total_row_count

string

Total number of the results (hits) for the query

results_table.rows[i].<column>

string

The value of the given <column>in the i-1th row in the results table, e.g. results_table.rows[0].foo will return the value of the foo column from the first row of results. Detection events contain a maximum of 10 rows in the results table.

Templating

Fields from the @alert object can be templated using double curly-braces {{and }} , for example, {{@alert.name}} will template the name of the detection rule.

Templating can be combined with normal strings, e.g Name: {{@alert.name}}.

Closing double-curly braces }}are expected whenever there are open double curly-braces {{, otherwise, the template will not parse.

The severity of the detection. See for more information.

Templating supports all . For example, {{@alert.results_table.total_row_count + 1}}will add 1 to the total row count from the @alert object.

scalar functions and operators
Writing Detection Rules
Detection severity
Format alert