SHOW ALERTS¶

Lists the alerts for which you have access privileges. The command can be used to list alerts for the current/specified database or schema, or across your entire account.

The output returns alert metadata and properties, ordered lexicographically by database, schema, and alert name (see Output in this topic for descriptions of the output columns). This is important to note if you wish to filter the results using the provided filters.

See also:: CREATE ALERT , ALTER ALERT, DROP ALERT , DESCRIBE ALERT

Syntax¶

SHOW [ TERSE ] ALERTS [ LIKE '<pattern>' ]
                      [ IN { ACCOUNT |
                             DATABASE [ <db_name> ] |
                             [ SCHEMA ] [ <schema_name> ]
                           }
                      ]
                      [ STARTS WITH '<name_string>' ]
                      [ LIMIT <rows> [ FROM '<name_string>' ] ]

Copy

Parameters¶

TERSE

Returns only a subset of the output columns:

created_on
name
kind (shows NULL for all alerts)
database_name
schema_name
schedule
state

LIKE 'pattern'

Filters the command output by object name. The filter uses case-insensitive pattern matching, with support for SQL wildcard characters (% and _).

For example, the following patterns return the same results:

... LIKE '%testing%' ...
... LIKE '%TESTING%' ...

Copy

IN ACCOUNT | [ DATABASE ] {db_name} | [ SCHEMA ] {schema_name}

Specifies the scope of the command, which determines whether the command lists records only for the current/specified database or schema, or across your entire account:

The DATABASE and SCHEMA keywords are not required; you can set the scope by specifying only the database or schema name. Likewise, the database or schema name is not required if the session currently has a database in use.

If DATABASE or SCHEMA is specified without a name and the session does not currently have a database in use, the parameter has no effect on the output.
If SCHEMA is specified with a name and the session does not currently have a database in use, the schema name must be fully qualified with the database name (e.g. testdb.testschema).

Default: Depends on whether the session currently has a database in use:

A database is in use: DATABASE is the default (i.e. the command returns the objects you have privileges to view in the database).
No database is in use: ACCOUNT is the default (i.e. the command returns the objects you have privileges to view in your account).

STARTS WITH 'name_string'

Filters the command output based on the string of characters that appear at the beginning of the object name. The string must be enclosed in single quotes and is case-sensitive. For example, the following return different results:

... STARTS WITH 'B' ...
... STARTS WITH 'b' ...

Copy

LIMIT rows [ FROM 'name_string' ]

Optionally limits the maximum number of rows returned, while also enabling “pagination” of the results. Note that the actual number of rows returned might be less than the specified limit (e.g. the number of existing objects is less than the specified limit).

The optional FROM 'name_string' subclause effectively serves as a “cursor” for the results. This enables fetching the specified number of rows following the first row whose object name matches the specified string:

The string must be enclosed in single quotes and is case-sensitive.
The string does not have to include the full object name; partial names are supported.

Default: No value (no limit is applied to the output)

Note

Both FROM 'name_string' and STARTS WITH 'name_string' can be combined in the same statement; however, both conditions must be met or they cancel out each other and no results are returned.

In addition, objects are returned in lexicographic order by name, so FROM 'name_string' only returns rows with a higher lexicographic value than the rows returned by STARTS WITH 'name_string'.

For example:

... STARTS WITH 'A' LIMIT ... FROM 'B' would return no results.
... STARTS WITH 'B' LIMIT ... FROM 'A' would return no results.
... STARTS WITH 'A' LIMIT ... FROM 'AB' would return results (if any rows match the input strings).

Output¶

The command output provides alert properties and metadata in the following columns:

| created_on | name | database_name | schema_name | owner | comment | warehouse | schedule | state | condition | action |

Copy

Column	Description
`created_on`	Date and time when the alert was created.
`name`	Name of the alert.
`database_name`	Database in which the alert is stored.
`schema_name`	Schema in which the alert is stored.
`owner`	Role that owns the alert (i.e. has the OWNERSHIP privilege on the alert)
`comment`	Comment for the alert.
`warehouse`	Warehouse that provides the required resources to run the alert.
`schedule`	Schedule for evaluating the condition for the alert.
`state`	Specifies the state of the alert. An alert can have one of the following states: `suspended` `started`
`condition`	The text of the SQL statement that serves as the condition when the alert should be triggered.
`action`	The text of the SQL statement that should be executed when the alert is triggered.

Access Control Requirements¶

A role used to execute this SQL command must have at least one of the following privileges at a minimum:

Privilege	Object	Notes
OPERATE or OWNERSHIP	Alert	OWNERSHIP is a special privilege on an object that is automatically granted to the role that created the object, but can also be transferred using the GRANT OWNERSHIP command to a different role by the owning role (or any role with the MANAGE GRANTS privilege).

Note that operating on any object in a schema also requires the USAGE privilege on the parent database and schema.

For instructions on creating a custom role with a specified set of privileges, see Creating Custom Roles.

For general information about roles and privilege grants for performing SQL actions on securable objects, see Overview of Access Control.

Usage Notes¶

Only returns rows for an alert owner (i.e. the role with the OWNERSHIP privilege on an alert) or a role with the OPERATE privilege on an alert.
The command does not require a running warehouse to execute.
The value for LIMIT rows cannot exceed 10000. If LIMIT rows is omitted, the command results in an error if the result set is larger than 10K rows.

To post-process the output of this command, you can use the RESULT_SCAN function, which treats the output as a table that can be queried.

Examples¶

See Viewing Details About Alerts.