API
  1. API
  2. API workflows
  3. Monitoring, alerts, & logs

Linodes and alerts

​Akamai​ offers a new platform to improve event alerts, with its Akamai Cloud Pulse (ACLP) service. While we transition to the new platform, you can select between it and our legacy alerting system when configuring your Linodes.

This document covers how to implement the different systems for your Linodes, using the Linode API.

📘

ACLP and its support with various Akamai Cloud services are in varying states of availability:

  • The ACLP service as a whole—including its metrics and alerts functionality—is in Limited Availability. Talk to your ​Akamai​ account team about access to it.
  • Enabling ACLP alerts in your Linode is in Beta. With access to the ACLP service, you may also be eligible to participate in the Beta program that lets you customize ACLP alerts in your Linodes. Talk to your account team about participation.

ACLP vs. legacy event alerting

With the release of ACLP, we now offer two alerts formats for your Linode:

  • ACLP alerts format. ACLP lets you customize monitoring and alerting for your Akamai Cloud services. You can configure custom metrics to be monitored and apply user-generated alerts that will be executed when thresholds you set for those metrics are met. You can create custom notification channels to distribute the alerts, or use system-related alerts that are pre-defined by ​Akamai​ for common monitoring events.

  • Legacy alerts format. This applies to legacy alerts that are sent for specific, pre-defined events. When you create a new Linode, various new event alerts are automatically added to it, with default settings. You can later customize these settings by updating your Linode.

Put simply, ACLP lets you customize monitoring and alerts and apply this while creating your Linode, while the legacy alerts format automatically applies alerts for common events to your Linode, after you create it.

👍

For more information on the benefits of the new monitoring experience, see Transition to the new Metrics and Alerts.

Add alerts to a new Linode

These workflows cover the creation of a new Linode, and adding alerts to it, for specific events.

📘

You can only use one alerts format. If you use ACLP alerts format for a new Linode, you can't revert to the legacy alerts format. However, an existing Linode using the legacy alerts format can be updated to use the new ACLP alerts format.

With this new service, you can add alerts to your Linode while you're creating it. This is what we refer to as ACLP alerts format. You can add pre-defined system alerts or user alerts that you custom build.

Create a Linode with system alerts

Beta Quickly add some pre-defined alerts to a new Linode while creating it:

  1. Run the List alert definitions operation, filtering on a type of system.

  2. Review the available system alerts in the response, and store the id for each one you want to include for your Linode. Ensure the selected alerts have a status of enabled.

    {
  "data": [
    {
      "alert_channels": [
        {
          "id": 10000,
          "label": "Read-Write Channel",
          "type": "email",
          "url": "/monitor/alert-channels/10000"
        }
      ],
      "class": "dedicated",
      "created": "2025-03-20 01:42:11",
      "created_by": "system",
      "description": "Alert for my PostgreSQL database",
      "entity_ids": [
        "126905",
        "126906",
        "137435",
        "141496",
        "190003",
        "257625",
        "257626"
      ],
      "has_more_resources": false,
      "id": 10000, # Store value
      "label": "High Memory Usage Plan Dedicated",
      "rule_criteria": {
        "rules": [
          {
            "aggregate_function": "avg",
            "dimension_filters": [
              {
                "dimension_label": "node_type",
                "label": "Node Type",
                "operator": "eq",
                "value": "primary"
              }
            ],
            "label": "Memory Usage",
            "metric": "memory_usage",
            "operator": "eq",
            "threshold": 95,
            "unit": "percent"
          }
        ]
      },
      "service_type": "dbaas",
      "severity": 2,
      "status": "enabled", # Verify status
      "trigger_conditions": {
        "criteria_condition": "ALL",
        "evaluation_period_seconds": 300,
        "polling_interval_seconds": 300,
        "trigger_occurrences": 3
      },
      "type": "system",
      "updated": "2025-03-20 01:42:11",
      "updated_by": "system"
    }
  ],
  "page": 1,
  "pages": 1,
  "results": 1
}

  3. Run the Create a Linode operation. Include the alerts object in the request and apply the id values for all of the alerts you stored, in the system_alerts array:

    "alerts": {
  "system_alerts": [
    10000,
    10001
  ],
  "user_alerts": []
},
...

  4. Build out the rest of the request using relevant settings for your Linode.

Create a Linode with user alerts

Beta Create a custom-built alert and add it to a new Linode:

  1. Run the Create an alert definition operation to create a new user alert.

  2. Store the id from the response as your alert_id.

    {
  "alert_channels": [
    {
      "id": 10001,
      "label": "High Memory Usage Plan Shared",
      "type": "alerts-definitions",
      "url": "/monitor/alerts-definitions/10001"
    }
  ],
  "class": "dedicated",
  "created": "2025-03-20T01:42:11",
  "created_by": "John Q. Linode",
  "description": "My alert for database memory over-usage.",
  "entity_ids": [
    "126905",
    "126906"
  ],
  "has_more_resources": false,
  "id": 56789, # Store this

  3. Run the Get an alert operation and review the status from the response. Repeat until this is displayed as enabled.

    {
  "alert_channels": [
    {
      "id": 10001,
      "label": "High Memory Usage Plan Shared",
      "type": "alerts-definitions",
      "url": "/monitor/alerts-definitions/10001"
    }
  ],
  "class": "dedicated",
  "created": "2025-03-20T01:42:11",
  "created_by": "John Q. Linode",
  "description": "My alert for database memory over-usage.",
  "entity_ids": [
    "126905",
    "126906"
  ],
  "has_more_resources": false,
  "id": 56789,
  "label": "Databases memory usage alert",
  "rule_criteria": {
    "rules": [
      ...
    ]
  },
  "service_type": "dbaas",
  "severity": 2,
  "status": "enabled", # Verify status
  "trigger_conditions": {
    "criteria_condition": "ALL",
    "evaluation_period_seconds": 300,
    "polling_interval_seconds": 300,
    "trigger_occurrences": 3
  },
  "type": "user",
  "updated": "2025-03-20T01:42:11",
  "updated_by": "John Q. Linode"
}

  4. Run the Create a Linode operation. Include the alerts object in the request and apply your stored alert_id in the user_alerts array:

    "alerts": {
  "system_alerts": [],
  "user_alerts": [
    56789
  ]
},
...

  5. Build out the rest of the request using relevant settings for your Linode.

Disable alerts on a new Linode

You can disable all alerts on a new Linode—both legacy alerts and ACLP alerts formats:

  1. Run the Create a Linode operation, and include the alerts object in the request. Include both the system_alerts and user_alerts parameters as empty arrays:

    "alerts": {
  "system_alerts": [],
  "user_alerts": []
},

  2. Configure the remaining fields as necessary and submit the the reques. The alerts object in the response should look like this:

    {
  "alerts": {
  "cpu": 0,
  "io": 0,
  "network_in": 0,
  "network_out": 0,
  "system_alerts": [],
  "transfer_quota": 0,
  "user_alerts": []
},

Now, all alerts are disabled for the Linode.

Update alerts

These workflows cover updating an existing Linode, to manage alerts.

Update from legacy to ACLP alerts format

Beta Update legacy format to ACLP format alerts:

  1. Run the List Linodes operation and store the id for the target Linode as your linodeId.

  2. Run the List alert definitions operation and store the identifiers for new alerts you want to add. Get the id for each as well as its type—either system or user.

  3. Run the Update a Linode operation, using the stored linodeId value. In the request:

    • Include the system_alerts and user_alerts arrays in the alerts object. Populate each with the applicable stored alert definition identifiers.

    • Leave the legacy alerts format parameters out. Leave the cpu, io, network_in, network_out, and transfer_quota parameters out of the request.

    "alerts": {
  "system_alerts": [
    10000
  ],
  "user_alerts": [ 
    56789,
    56790
  ]
},
    📘

    This process assumes you've already created any user alert definitions you may want to use.

Update existing ACLP alerts

Beta Modify your existing ACLP settings on your Linode:

  1. Run the List Linodes operation:

    • Store the id for the target Linode as your linodeId.

    • Review the alerts object in the response. Store the alert definition identifiers from the system_alerts and user_alerts arrays.

    "alerts": {
  "cpu": 0,
  "io": 0,
  "network_in": 0,
  "network_out": 0,
  "transfer_quota": 0
  "system_alerts": [
    10000, # Store value
    10001  # Store value
  ],
  "user_alerts": [ 
    56789  # Store value
  ]
},

  2. Run the List alert definitions operation. Review the response:

    • Use the stored identifiers to review your existing alerts. The id value for each alert definition is accompanied by all of the details for that alert. Determine if you want to keep that alert for your Linode.

    • Store the identifiers for new alerts you want to add. Get the id for each as well as its type—either system or user.

  3. Run the Update a Linode operation, using the stored linodeId value. In the request:

    • Include the system_alerts and user_alerts arrays in the alerts object. Populate each with the applicable stored alert definition identifiers.

    • Leave the legacy alerts format parameters out. Leave the cpu, io, network_in, network_out, and transfer_quota parameters out of the request.

    "alerts": {
  "system_alerts": [
    10000, # Kept from previous
    10001  # Kept from previous
  ],
  "user_alerts": [ 
    56789, # Kept from previous
    56790, # Newly added alert definition
    56791 # Newly added alert definition
  ]
},
    📘

    To keep existing ACLP alerts, you need to include them in the request. The API resets values that aren't included.

  4. Configure the remaining parameters in the request as necessary.

Disable all alerts in an existing Linode

If you already have either format of alert applied in a Linode, and you want to fully disable alerting, you can by updating that Linode.

  1. Run the List Linodes operation and store the id for the target Linode as your linodeId.

  2. Run the Update a Linode operation, using the stored linodeId value. Include both the system_alerts and user_alerts parameters as empty arrays:

    "alerts": {
  "system_alerts": [],
  "user_alerts": []
},

  3. Configure the remaining parameters in the request as necessary.

All alerts are now disabled for the target Linode. This includes both ACLP alert and format legacy alert format.

Clone a Linode and alerts

Cloning a Linode duplicates its configuration profiles, disks, and interfaces to a different Linode.

When you clone to a new Linode, the current alerts settings for the source Linode are not carried forward to the new instance. You can apply existing alerts settings for the new Linode, based on the alerts format.

📘

If you intend to clone to an existing Linode, this does not apply. The alerts settings applied on the existing Linode where you're cloning to will still apply. (You can update alert settings on this existing Linode by updating it.)

Beta Clone and include any existing alerts from the source Linode in the request:

  1. Run the List Linodes operation and store the id for the clone source as your linodeId.

  2. Run the Get a Linode operation, using the stored linodeId value and review the response:

    • system_alerts and user_alerts. Store the identifier values from these arrays as necessary.
    • type. Store this as your linodeType.
    {
  "alerts": {
    "cpu": 0,
    "io": 0,
    "network_in": 0,
    "network_out": 0,
    "system_alerts": [
      10000, # Store value
      10001  # Store value
    ],
    "transfer_quota": 0,
    "user_alerts": [
      56789 # Store value
    ]
  },
  ...
  "type": "g6-standard-1", # Store value
  
},
...

  3. Optionally, run the List types operation. Review the capabilities, disk, memory, gpus, and network_out for each class. You can clone to a new Linode that has at least the same resources as your stored linodeType. If you select a larger class, store it as your linodeType.

  4. Run the Clone a Linode operation. Include at least these fields in the request:

    • alerts. Apply the alerts identifier values you stored from the source, in the appropriate array.
    • type. Set this to your stored linodeType.
    "alerts": {
  "system_alerts": [
    10000,
    10001
  ],
  "user_alerts": [
    56789
  ]
},
"type": "g6-standard-1",
...

  5. You can also add new alert definitions to the clone. Run the List alert definitions operation and store the id values for the relevant definitions. Add them to the system_alerts and user_alerts arrays, accordingly.

  6. Build out the rest of the request using relevant settings to clone the Linode.

🚧

You can't include the linode_id field in the request, to target an existing Linode. This process only applies when cloning to a new Linode.

Rebuild a Linode and alerts

Rebuilding a Linode deletes all of its configuration profiles and disks and deploys a new image to a different Linode.

When you rebuild to a new Linode, its alerts settings are deleted along with its configuration profiles and disks. You can re-apply the same alerts settings on the new, rebuilt Linode, based on the alerts format.

📘

If you intend to rebuild to an existing Linode, this does not apply. The alerts settings applied on the existing Linode that's the target for the rebuild will still apply. (You can update alert settings on this existing Linode by updating it.)

Beta Include any existing alerts from the source Linode in the request:

  1. Run the List Linodes operation and store the id for the rebuild source as your linodeId.

  2. Run the Get a Linode operation, using the stored linodeId value and review the response:

    • system_alerts and user_alerts. Store the identifier values from these arrays as necessary.
    • type. Store this as your linodeType.
    • image. This is the current image type in use on the source.
    {
  "alerts": {
    "cpu": 0,
    "io": 0,
    "network_in": 0,
    "network_out": 0,
    "system_alerts": [
      10000, # Store value
      10001  # Store value
    ],
    "transfer_quota": 0,
    "user_alerts": [
      56789 # Store value
    ]
  },
  ...
  "image": "linode/debian10", # Review value
  "type": "g6-standard-1", # Store value
},
...

  3. Run the List images operation. Review the available image types and store the id for the desired one as your imageId.

  4. Optionally, run the List types operation. Review the capabilities, disk, memory, gpus, and network_out for each class. You can rebuild to a new Linode that has at least the same resources as your stored linodeType. If you select a larger class, store it as your linodeType.

  5. Run the Rebuild a Linode operation. Include at least these fields in the request:

    • alerts. Apply the alerts identifier values you stored from the source, in the appropriate array.
    • type. Set this to your stored linodeType.
    • image: Set this to your stored imageId.
    "alerts": {
  "system_alerts": [
    10000,
    10001
  ],
  "user_alerts": [
    56789
  ]
},
"type": "g6-standard-1",
"image": "linode/debian11",
...

  6. You can also add new alert definitions to the clone. Run the List alert definitions operation and store the id values for the relevant definitions. Add them to the system_alerts and user_alerts arrays, accordingly.

  7. Build out the rest of the request using relevant settings to clone the Linode.

🚧

You can't include the linode_id field in the request, to target an existing Linode. This process only applies when rebuilding to a new Linode.

Updated 10 days ago

Did this page help you?

Updated 10 days ago

Did this page help you?