Skip to main content

Actions

An action is how monitoring reaches out when an alert fires. An alert on its own only detects a condition; the action turns that into an email, a text message, or a request to another system. An action is reusable: define a response once and point any number of alerts at it. This page lists your actions and is where you create and edit them.

Existing actions are shown in a table, one row per action, with its name, type, and destination. The destination column shows where each action delivers, the webhook URL or the recipient address or number, so you can confirm at a glance that an action points where you expect without opening it.

An action's type is chosen when you create it. To deliver the same alert a different way, such as by SMS instead of email, create a second action and add it alongside the first on the alert.

Action types​

Every action is one of three types, chosen when you create it. They differ in what they can reach and what you need to set up.

Email​

Best for routing an alert to a person or a shared team inbox. Email goes through SendGrid, so you need a SendGrid account and its API key. The From Address must be a sender verified in SendGrid, or the message will not deliver, and To Addresses takes one or more recipients. The Subject and Body accept the variables described below.

Webhook​

The most flexible type, and the one to reach for when the response is automation rather than a person. It sends an HTTP request to any URL, with the Method and optional Authentication (Basic, Bearer token, or None) you choose, and a Body you define. A Body format toggle selects JSON or plain text. The body accepts the same variables as the other types, so the receiving system gets the full context of what fired:

{
  "service": "{serviceName}",
  "metric": "{metric}",
  "value": "{metricValue}",
  "threshold": "{thresholdName}",
  "severity": "{severity}",
  "time": "{timestamp}"
}

Because the target is any URL, the webhook is also how you drive automation. Point it at a TagoIO device or endpoint, and the incoming data can run an Analysis that reacts on its own, such as disabling devices or generating a report.

SMS​

For alerts that need to reach someone away from a screen, such as your highest thresholds. Text messages go through Twilio, so you need a Twilio account (its Account SID and Auth Token) and a Twilio From Number to send from. The recipients in To Numbers receive the Message Template with its variables filled in.

Message content​

The subject, body, and message fields accept variables that the monitor fills in when an alert fires, so each notification arrives with the context of what happened:

  • {serviceName}: the service that triggered the alert.
  • {serviceType}: the service type.
  • {metric}: the metric that crossed the threshold, with its threshold name.
  • {metricName}: the raw metric name on its own.
  • {metricValue}: the metric's value at trigger time.
  • {thresholdName}: the threshold that fired.
  • {severity}: the threshold's severity (info, warning, critical, ...).
  • {timestamp}: when the alert fired.

For example, an email action for a database CPU alert might use:

  • Subject: [{thresholdName}] {serviceName} - {metric} at {metricValue}
  • Body: {metric} on {serviceName} crossed the {thresholdName} threshold. Current value: {metricValue}. Severity: {severity}. Time: {timestamp}.

When that alert fires at 92% CPU, the email arrives with a subject like [Critical] Main Database - CPU Utilization at 92%.

The email and SMS types use SendGrid and Twilio, the same providers the project uses for system notifications. For provider account setup and deliverability notes, see Integrations.

Connecting actions to alerts​

Actions do not fire on their own. An alert points at them, as the rule's default actions or per threshold, and runs them when a threshold is crossed. Define the action first, then select it on the alert.