alert_definitions

Creates, updates, deletes, gets or lists an alert_definitions resource.

Overview

Name	alert_definitions
Type	Resource
Id	linode.monitor.alert_definitions

Fields

The following fields are returned by SELECT queries:

get_alert_definition

Returns the specified alert definition.

Name	Datatype	Description
id	integer	The unique identifier for the alert definition.
alert_channels	array	The alert channels set up for use with this alert. Run the List alert channels operation to see all of the available channels.
class	string	The plan type for the Managed Database cluster, either shared or dedicated. This only applies to a system alert for a service_type of dbaas (Managed Databases). For user alerts for dbaas, this is returned as null. (example: dedicated)
created	string (date-time)	When the alert definition was created. (example: 2025-03-20 01:42:11)
created_by	string	For a user alert definition, this is the user on your account that created it. For a system alert definition, this is returned as system. (example: system)
description	string	An additional description for the alert definition. (example: Alert for my PostgreSQL database)
entity_ids	array	The id for each individual entity from a service_type. Get this value by running the list operation for the appropriate entity. For example, if your entity is one of your PostgreSQL databases, run the List PostgreSQL Managed Databases operation and store the id for the appropriate database from the response. > 📘 > > The format type for an entity_id may vary, based on the Akamai Cloud service_type. For example, the dbaas service returns an integer value for an id, that you'd use for the entity_id, while other services may return a string for their id. With the Alerts operations, all of these formats are recognized as an entity_id, when you include them as a string.
has_more_resources	boolean	Whether there are additional entity_ids associated with the alert for which the user doesn't have at least read-only access.
label	string	The name of the alert definition. This is used for display purposes in Akamai Cloud Manager. (example: High Memory Usage Plan Dedicated)
rule_criteria	object	Details for the rules required to trigger the alert.
service_type	string	The identifier for the Akamai Cloud Computing service. Use this value to call out the service in other Monitor operations in the API. Currently, only the Managed Databases (dbaas) service is supported. (example: dbaas)
severity	integer	The severity of the alert. Supported values include 3 for info, 2 for low, 1 for medium, and 0 for severe.
status	string	The current status of the alert. This can be either enabled, disabled, in progress, or failed. (example: enabled)
trigger_conditions	object	The conditions that need to be met to send a notification for the alert.
type	string	The type of alert. This can be either user for an alert specific to the current user, or system for one that applies to all users on your account. (example: system)
updated	string (date-time)	When the alert definition was last updated. This is the same as created if the alert definition hasn't been updated. (example: 2025-03-20 01:42:11)
updated_by	string	For a user alert definition, this is the user on your account that last updated it. For a system alert definition, this is returned as system. If it hasn't been updated, this value is the same as created_by. (example: system)

get_alert_definitions_for_service_type

Returns a paginated list of alert definitions for the specified service type.

Name	Datatype	Description
data	array
page	integer	Read-only The current page.
pages	integer	Read-only The total number of pages.
results	integer	Read-only The total number of results.

get_alert_definitions

Returns a paginated list of all alert definitions.

Name	Datatype	Description
data	array
page	integer	Read-only The current page.
pages	integer	Read-only The total number of pages.
results	integer	Read-only The total number of results.

Methods

The following methods are available for this resource:

Name	Accessible by	Required Params	Optional Params	Description
get_alert_definition	select			Beta Returns a specific alert definition. Include the appropriate service_type and alert_id as path parameters. > 📘 > > - This operation is beta. Call it using the v4beta path in its URL. > > - Currently, only the Managed Databases (dbaas) service type is supported. OAuth scopes. <br /> monitor:read_only<br /> Learn more... - Learn more...
get_alert_definitions_for_service_type	select			Beta Returns all available alert definitions for a specific service type. Include the appropriate service_type as a path parameter. > 📘 > > - This operation is beta. Call it using the v4beta path in its URL. > > - Currently, only the Managed Databases (dbaas) service type is supported. OAuth scopes. <br /> monitor:read_only<br /> Learn more... - Learn more...
get_alert_definitions	select			Beta Returns all available alert definitions on your account. > 📘 > > - This operation is beta. Call it using the v4beta path in its URL. > > - Filtering is supported for specific objects, labeled as Filterable. However, only the +and and +or operators are supported, and you can't nest filter operators. OAuth scopes. <br /> monitor:read_only<br /> Learn more... - Learn more...
post_alert_definition_for_service_type	insert	data__label, data__severity, data__rule_criteria, data__trigger_conditions, data__channel_ids		Beta Create a new alert definition for a specific service type. Include the appropriate service_type as a path parameter. These are referred to as user alerts. You need read_only access to the scope for the selected service_type. > 📘 > > - This operation is beta. Call it using the v4beta path in its URL. > > - Currently, only the Managed Databases (dbaas) service type is supported. OAuth scopes. <br /> monitor:read_write<br /> Learn more... - Learn more...
put_alert_definition	replace			Beta Update an existing alert definition. Include the appropriate service_type and alert_id as path parameters. You need read_only access to the scope for the selected service_type. Only include the objects in the request that you want to update. Leave any object out of the request to leave it set as is. > 📘 > > - This operation is beta. Call it using the v4beta path in its URL. > > - Currently, only the Managed Databases (dbaas) service type is supported. User alert definitions When updating an alert definition you've created, you can change the status to enabled or disabled. You can also modify the label, description, severity, entity_ids, rule_criteria, trigger_conditions, and channel_ids objects. If updating the entity_ids, rule_criteria, or channel_ids list objects, these points apply: - If you want to keep an existing item, you need to include it in the list. - If you want to remove an existing item, leave it out of the list. - To add a new item, include it in the list. - You can't pass an empty list to remove all items. This doesn't apply to the entity_ids or dimension_filters (in rule_criteria) list objects, because they are optional, while all other list objects are required. System alert definitions These are the default alert definitions offered by Akamai. You can only edit the entity_ids list object for these alerts. All of the points above regarding editing a list object apply here, too. OAuth scopes. <br /> monitor:read_write<br /> Learn more... - Learn more...
delete_alert_definition	delete			Beta Delete a specific alert definition on your account. Include the appropriate service_type and alert_id as path parameters. > 📘 > > - This operation is beta. Call it using the v4beta path in its URL. > > - You need read_only access to the scope for the target service_type. > > - An alert definition with a type of system can't be deleted. > > - Currently, only the Managed Databases (dbaas) service type is supported. Learn more... Learn more...

Parameters

Parameters can be passed in the WHERE clause of a query. Check the Methods section to see which parameters are required or optional for each operation.

Name	Datatype	Description

SELECT examples

get_alert_definition

Beta Returns a specific alert definition. Include the appropriate service_type and alert_id as path parameters.

> 📘
>
> - This operation is beta. Call it using the v4beta path in its URL.
>
> - Currently, only the Managed Databases (dbaas) service type is supported. OAuth scopes.

<br /> monitor:read_only<br />

Learn more...

-

Learn more...

SELECT
id,
alert_channels,
class,
created,
created_by,
description,
entity_ids,
has_more_resources,
label,
rule_criteria,
service_type,
severity,
status,
trigger_conditions,
type,
updated,
updated_by
FROM linode.monitor.alert_definitions;

get_alert_definitions_for_service_type

Beta Returns all available alert definitions for a specific service type. Include the appropriate service_type as a path parameter.

> 📘
>
> - This operation is beta. Call it using the v4beta path in its URL.
>
> - Currently, only the Managed Databases (dbaas) service type is supported. OAuth scopes.

<br /> monitor:read_only<br />

Learn more...

-

Learn more...

SELECT
data,
page,
pages,
results
FROM linode.monitor.alert_definitions;

get_alert_definitions

Beta Returns all available alert definitions on your account.

> 📘
>
> - This operation is beta. Call it using the v4beta path in its URL.
>
> - Filtering is supported for specific objects, labeled as Filterable. However, only the +and and +or operators are supported, and you can't nest filter operators. OAuth scopes.

<br /> monitor:read_only<br />

Learn more...

-

Learn more...

SELECT
data,
page,
pages,
results
FROM linode.monitor.alert_definitions;

INSERT examples

post_alert_definition_for_service_type

Beta Create a new alert definition for a specific service type. Include the appropriate service_type as a path parameter. These are referred to as user alerts. You need read_only access to the scope for the selected service_type.

> 📘
>
> - This operation is beta. Call it using the v4beta path in its URL.
>
> - Currently, only the Managed Databases (dbaas) service type is supported. OAuth scopes.

<br /> monitor:read_write<br />

Learn more...

-

Learn more...

INSERT INTO linode.monitor.alert_definitions (
data__channel_ids,
data__description,
data__entity_ids,
data__label,
data__rule_criteria,
data__severity,
data__trigger_conditions
)
SELECT 
'{{ channel_ids }}' --required,
'{{ description }}',
'{{ entity_ids }}',
'{{ label }}' --required,
'{{ rule_criteria }}' --required,
{{ severity }} --required,
'{{ trigger_conditions }}' --required
RETURNING
id,
alert_channels,
class,
created,
created_by,
description,
entity_ids,
has_more_resources,
label,
rule_criteria,
service_type,
severity,
status,
trigger_conditions,
type,
updated,
updated_by
;

Manifest

# Description fields are for documentation purposes
- name: alert_definitions
  props:
    - name: channel_ids
      value: array
      description: >
        The identifiers for the alert channels to use for the alert. Run the [List alert channels](https://techdocs.akamai.com/linode-api/reference/get-alert-channels) operation and store the `id` for the applicable channels.
        
    - name: description
      value: string
      description: >
        An additional description for the alert definition.
        
    - name: entity_ids
      value: array
      description: >
        The `id` for each individual entity from a `service_type`. Get this value by running the list operation for the appropriate entity. For example, if your entity is one of your PostgreSQL databases, run the [List PostgreSQL Managed Databases](https://techdocs.akamai.com/linode-api/reference/get-databases-postgre-sql-instances) operation and store the `id` for the appropriate database from the response.

> 📘
>
> - You need `read_only` access to the [scope](https://techdocs.akamai.com/linode-api/reference/get-started#oauth-reference) for the `service_type` for each of the `entity_ids`.
>
> - The format `type` for an `entity_id` may vary, based on the Akamai Cloud `service_type`. For example, the `dbaas` service returns an integer value for an `id`, that you'd use for the `entity_id`, while other services may return a string for their `id`. With the Alerts operations, all of these formats are recognized as an `entity_id`, when you include them as a `string`.
        
    - name: label
      value: string
      description: >
        The name of the alert definition. This is used for display purposes in Akamai Cloud Manager.
        
    - name: rule_criteria
      value: object
      description: >
        Details for the rules required to trigger the alert.
        
    - name: severity
      value: integer
      description: >
        The severity of the alert. Supported values include `3` for info, `2` for low, `1` for medium, and `0` for severe.
        
      valid_values: ['0', '1', '2', '3']
    - name: trigger_conditions
      value: object
      description: >
        The conditions that need to be met to send a notification for the alert.
        

REPLACE examples

put_alert_definition

Beta Update an existing alert definition. Include the appropriate service_type and alert_id as path parameters. You need read_only access to the scope for the selected service_type. Only include the objects in the request that you want to update. Leave any object out of the request to leave it set as is.

> 📘
>
> - This operation is beta. Call it using the v4beta path in its URL.
>
> - Currently, only the Managed Databases (dbaas) service type is supported.

User alert definitions

When updating an alert definition you've created, you can change the status to enabled or disabled. You can also modify the label, description, severity, entity_ids, rule_criteria, trigger_conditions, and channel_ids objects. If updating the entity_ids, rule_criteria, or channel_ids list objects, these points apply:

- If you want to keep an existing item, you need to include it in the list.

- If you want to remove an existing item, leave it out of the list.

- To add a new item, include it in the list.

- You can't pass an empty list to remove all items. This doesn't apply to the entity_ids or dimension_filters (in rule_criteria) list objects, because they are optional, while all other list objects are required.

System alert definitions

These are the default alert definitions offered by Akamai. You can only edit the entity_ids list object for these alerts. All of the points above regarding editing a list object apply here, too. OAuth scopes.

<br /> monitor:read_write<br />

Learn more...

-

Learn more...

REPLACE linode.monitor.alert_definitions
SET 
data__channel_ids = '{{ channel_ids }}',
data__description = '{{ description }}',
data__entity_ids = '{{ entity_ids }}',
data__label = '{{ label }}',
data__rule_criteria = '{{ rule_criteria }}',
data__severity = {{ severity }},
data__status = '{{ status }}',
data__trigger_conditions = '{{ trigger_conditions }}'
WHERE 

RETURNING
id,
alert_channels,
class,
created,
created_by,
description,
entity_ids,
has_more_resources,
label,
rule_criteria,
service_type,
severity,
status,
trigger_conditions,
type,
updated,
updated_by;

DELETE examples

delete_alert_definition

Beta Delete a specific alert definition on your account. Include the appropriate service_type and alert_id as path parameters.

> 📘
>
> - This operation is beta. Call it using the v4beta path in its URL.
>
> - You need read_only access to the scope for the target service_type.
>
> - An alert definition with a type of system can't be deleted.
>
> - Currently, only the Managed Databases (dbaas) service type is supported.

Learn more...

Learn more...

DELETE FROM linode.monitor.alert_definitions;