Alerting: Triggers

Overview

Use this page to create, test, and manage alert triggers. A trigger is a configured delivery method (Email, Webhook, SMS, or WhatsApp) that alert profiles use to send a notification. Separating delivery from timing lets you reuse the same webhook or mailbox across many alert conditions instead of re-entering connection details every time.

Triggers sit at the start of LoadGen's alert setup chain: Trigger, then Alert Profile, then Uptime Check. You create a trigger here first. An Alert Profile (Alerting: Profiles) then binds that trigger and defines the conditions under which it fires. Finally, each Uptime Check's Step 6 Alerting setting links the profile to specific checks; skipping that link means the profile fires on every enabled check by default.

This page lists every trigger you've configured with its delivery type, enabled status, which module's profiles use it, and when it last sent a notification. From here you create new triggers, send a real test notification to confirm one still works, edit its connection details, or delete it when a channel is retired.

Key concepts

• Trigger - A configured delivery method, Email, Webhook, SMS, or WhatsApp, that sends the actual notification message when an alert fires. (related: Alerting: Profiles)
• Alert Profile - A set of conditions that decides when to fire a notification, and which trigger delivers it. (related: Alerting: Profiles)
• Uptime Check - A monitored endpoint or service whose Step 6 Alerting setting links an alert profile to it, scoping which checks use that profile instead of letting it fire on every check by default. (related: Uptime Monitoring: Checks)

When to use it

• Setting up alerting for the first time and defining how notifications will be delivered.
• Onboarding a new notification channel, for example a different webhook endpoint or an on-call phone number, for an existing alert profile.
• Confirming a configured channel still works with Send test notification before relying on it during an incident.
• Auditing which triggers are currently in use by which module (Used By column) before changing or retiring a channel.
• Editing the destination or connection details of an existing trigger.
• Removing a trigger that is no longer needed, for example after a team channel changes.

Before you begin

• Know which delivery method you need, Email, Webhook, SMS, or WhatsApp, and have its connection details ready (a mailbox, a webhook URL, or a phone number).
• Hold the Alerting trigger-create permission for your role, configured on Operations: Permissions; without it, Create Trigger does not appear.
• If the delivery method needs a sending account or credential, set it up first on Configuration: Notification Accounts.
• Identify the Alert Profile this trigger will support, or plan to create one next on Alerting: Profiles, since a trigger by itself does not send anything until a profile binds it.

Common workflows

Create a new alert trigger

Persona: Administrator setting up a new notification channel

1. Select Create Trigger at the top of the Alert Triggers table.
   • Expect: The trigger editor opens with fields for a name and a delivery type (Email, Webhook, SMS, or WhatsApp).
2. Enter a recognizable name such as Vega evening logoff wave, choose the delivery type, fill in its connection details, then save.
   • Expect: The editor closes and the new trigger appears as a row in the table with Status Active and Last Used showing Never.

Verify: The trigger you created appears in the Alert Triggers table with the name and delivery type you chose; it has no effect on notifications yet until you bind it to an Alert Profile.

Test a trigger before relying on it

Persona: Operator confirming a channel works

1. Select the bolt icon (Send test notification) on the trigger's row.
   • Expect: LoadGen sends a real test message through the trigger's configured channel immediately.
2. Check the destination, inbox, webhook log, or phone, for the test message.
   • Expect: A received message confirms the trigger is configured correctly; a failed send shows an inline error naming the reason.

Verify: The destination received the test message, and the row's Last Used value updates away from Never.

Steps

Step 1

Open Triggers under Alerting.

Expected result: The Alert Triggers table loads showing each configured trigger with its delivery Type, Status, Used By module, Last Used time, and Created By, plus an onboarding banner explaining the Trigger, Profile, Check setup chain.

This page is where you review existing triggers and start creating or testing one before building out alert profiles and scoping checks.

• The banner explains the 3-step chain: create a Trigger here, bind it to an Alert Profile, then link that profile under a specific Uptime Check's Step 6 Alerting.
• The NAME cell is clickable and opens the trigger for editing or viewing.
• The row's ACTIONS icons (test, edit, delete) reflect what your role is permitted to do with this trigger.

Column reference

Controls reference

Create Trigger

Opens the trigger editor in create mode so you can define a new delivery method and its connection details.

When to use: Use it when alert profiles need a new channel to notify through, for example a different webhook endpoint or an on-call phone number.

Side effects: Read-only until saved: opens the editor only, no trigger is created until you save inside it.

Open trigger

Opens the selected trigger by selecting its name.

When to use: Use it to inspect or change an existing trigger's configuration.

Side effects: Read-only action; opens editable only if your role holds the update permission for every module currently using the trigger, otherwise it opens read-only.

Send test notification

Sends a real test notification through the trigger's configured channel.

When to use: Use it after creating or editing a trigger to confirm the channel actually delivers before relying on it during an incident.

Side effects: Mutating in effect: it sends an actual message to the configured destination, such as a webhook post or an email. It does not change the trigger's saved configuration. Disabled if your role doesn't hold the test permission for every module using the trigger.

Edit

Opens the trigger editor pre-filled with the trigger's current configuration.

When to use: Use it to change the destination, name, or connection details of an existing trigger.

Side effects: Mutating once saved: updates the configuration for every alert profile already using this trigger. Unavailable if your role doesn't hold the update permission for every module using it.

Delete

Removes the trigger.

When to use: Use it to retire a channel that is no longer needed, for example a decommissioned webhook endpoint.

Side effects: Mutating and immediate: deletes the trigger. If it is bound to alert profiles in a module outside your role's scope, the delete is refused with a reason naming that module.

Dismiss

Hides the Trigger, then Profile, then Check onboarding banner.

When to use: Use it once you understand the alert setup chain and no longer need the reminder.

Side effects: Read-only UI preference; does not affect any trigger data, and the dismissal is remembered for future visits.

Verify the result

After creating or editing a trigger, it appears in the Alert Triggers table with the delivery Type you chose and a Status of Active. Selecting Send test notification on that row delivers a real message to the configured destination; if the destination receives it, the trigger is correctly configured, and Last Used updates away from Never. If the row instead shows a view-only Actions column with no test, edit, or delete icon, your role does not hold the required permission for every module using that trigger. Creating a trigger alone does not send anything until an Alert Profile binds it.

Troubleshooting

• Symptom: The Create Trigger button isn't visible. Fix: Your role doesn't hold the trigger-create permission for Alerting; ask an administrator to grant it on Operations: Permissions.
• Symptom: A row's Actions column shows no test, edit, or delete icon. Fix: An alert profile outside your role's module scope uses that trigger; open the row to see which module needs to be granted, or ask an administrator.
• Symptom: Send test notification doesn't seem to have an effect. Fix: It sends a real message, so check the actual destination (inbox, webhook log, phone) rather than this table; Last Used only updates after a successful send.
• Symptom: Deleting a trigger is refused with a module-specific message. Fix: Remove or reassign the alert profiles using it in that module on Alerting: Profiles first, or have someone holding that module's permission delete it.
• Symptom: A new trigger isn't producing any notifications for a check you expect. Fix: Creating the trigger alone doesn't wire it to anything; bind it to an Alert Profile and link that profile under the specific Uptime Check's Step 6 Alerting.

Related articles

• Next step: Alerting: Profiles - bind the new trigger to a profile that defines when it fires
• Next step: Uptime Monitoring: Checks - link the alert profile to specific checks under Step 6 Alerting to scope delivery
• Prerequisite: Configuration: Notification Accounts - configure the sending accounts a trigger's delivery method uses
• See also: Operations: Permissions - grant the create, update, test, and delete permissions that control what you can do with triggers