Send your first alert
Create a test alert, send its sample with one curl command and open the resulting incident.
How-to · Updated 2026-10-17 · Describes release 0.1.164
Before you start
Use a workspace whose Incident agent is Enabled (every new workspace starts with all agents on). No connection is needed for the test alert to open an incident and start an analysis, but without a verified read connection the analysis has almost no evidence to work with. You need a terminal with curl. An owner, or a custom role with pillars.manage, creates the test alert and the webhook token. Keep that token private.
1. Prepare the command
Open Alert intake & tokens (in the product: /portal/tokens#validation) in the intended workspace. Under Send a test alert, choose your sender's format and select Create test alert. The card shows the endpoint, a Sample payload carrying a correlation id, and a curl command.
Have the workspace's webhook token ready. A saved token is stored as a hash and cannot be revealed again, so use the token you already hold. If the workspace has none, or nobody holds it, Mint webhook token (confirmed with Mint token) issues a new one, shown once; the previous token stops working at once for every sender using that workspace's webhook. Through the API, POST /api/aiops/{tid}/webhook-token mints it; a personal access token needs the admin scope for that call.
2. Copy and run
Save the Sample payload as validation.json. The command under curl (fill the two placeholders) posts that file and has two placeholders: set AIOPS_URL to this platform's address and WEBHOOK_TOKEN to the token, for example export AIOPS_URL=https://aiops.example.com and export WEBHOOK_TOKEN=<your token>. Run the command from the folder that holds validation.json.
Run it once. Read the HTTP response before continuing. If curl reports a network or certificate error, resolve that connection first; do not disable TLS verification as a shortcut.
3. Open the result
Return to the Receipt under the test alert. Once the signal has arrived, open its linked incident. If it is still waiting, refresh the receipt and compare the endpoint, workspace and token against the command you ran.
Success means: the signal was received, linked to an incident and an investigation has a recorded result. An accepted HTTP response alone does not prove the investigation succeeded.
| What you see | What to do |
|---|---|
| The alert arrived but no analysis started | Read the incident's heading. Held for triage — … names the intake rule that held the alert. Run failed — … names why the run was refused or failed: Pause all agents is on, a daily or monthly cost limit is reached, the platform licence is expired or invalid, pillar disabled or unconfigured (the Incident agent is not Enabled), or a model provider error. Each cause and its fix is in Alert sources and intake rules. |
4. Connect your real sender
Use the same workspace's endpoint and token in your monitoring system. Choose its matching adapter, and include a stable service label so related signals become one piece of work. Keep resolved signals enabled so AIOps can observe recovery. A sender that cannot set a header, such as an SNS subscription or an Azure action group, uses the path form /webhook/<source>/<workspace-slug>/<token>. For CloudWatch, put severity=warning in the description of your first alarms: an alarm that declares no severity arrives as critical and opens a P1 incident, whose fix is an emergency change that needs two different approvers under the default change class policy. Running Dynatrace, Datadog, Grafana, CloudWatch, Azure Monitor or Robusta? Alerts from your observability platform has the setup for each.
Webhook reference · Follow the incident.