Axiom Alerting
You manage alerting in Axiom end-to-end: notifiers for routing and monitors for detection.
API Overview
Base URL: https://api.axiom.co/v2/ with Bearer token auth from .axiom.toml (project root or ~/.axiom.toml).
Monitors (/v2/monitors)
| Operation | Method | Path |
|---|---|---|
| List | GET | /v2/monitors |
| Get | GET | /v2/monitors/{id} |
| History | GET | /v2/monitors/{id}/history |
| Create | POST | /v2/monitors |
| Update | PUT | /v2/monitors/{id} |
| Delete | DELETE | /v2/monitors/{id} |
Notifiers (/v2/notifiers)
| Operation | Method | Path |
|---|---|---|
| List | GET | /v2/notifiers |
| Get | GET | /v2/notifiers/{id} |
| Create | POST | /v2/notifiers |
| Update | PUT | /v2/notifiers/{id} |
| Delete | DELETE | /v2/notifiers/{id} |
Prerequisites
- Run
scripts/setup - Ensure
.axiom.tomlhas a deployment:
toml[deployments.prod] url = "https://api.axiom.co" token = "xaat-your-token" org_id = "your-org-id"
Scripts
Core:
scripts/axiom-api <deploy> <method> <path> [body]
Monitor scripts:
scripts/monitor-list <deployment> [--json]scripts/monitor-get <deployment> <id>scripts/monitor-history <deployment> <id> <startTime> <endTime>scripts/monitor-create <deployment> <json-file>scripts/monitor-update <deployment> <id> <json-file>scripts/monitor-delete <deployment> <id>
Notifier scripts:
scripts/notifier-list <deployment> [--json]scripts/notifier-get <deployment> <id>scripts/notifier-create <deployment> <json-file>scripts/notifier-update <deployment> <id> <json-file>scripts/notifier-delete <deployment> <id>
Recommended Workflow
- Create notifier first.
- Create monitor and set
notifierIds. - Validate monitor behavior with
monitor-history. - Iterate monitor thresholds and schedule.
Workflow: End-To-End Alerting
- Run
scripts/setup. - List existing notifiers with
scripts/notifier-list <deployment>and reuse one if appropriate. - If no suitable notifier exists, create one with
scripts/notifier-create. - Create or update the monitor with
notifierIdsattached. - Validate with
scripts/monitor-history <deployment> <id> <startTime> <endTime>. - If behavior is noisy or silent, tune
threshold,rangeMinutes,intervalMinutes, and N-of-M trigger fields. - Re-check history after each change.
Best Practices
- Configure one channel per notifier.
- Use
emails(notrecipients) for email notifier payloads. - Prefer
triggerAfterNPositiveResults/triggerFromNRunsfor noisy signals. - Use explicit
bin()in monitor queries; avoidbin_auto()for alert logic. - For metrics-backed monitors, prefer
mplQueryfor definitions; API responses may include bothaplQueryandmplQuery.
Monitor Types And Operators
Monitor types:
ThresholdMatchEventAnomalyDetection
Operators:
AboveBelowAboveOrEqualBelowOrEqualAboveOrBelow
Monitor Field Reference
Core fields:
name: Human-readable monitor name.type:Threshold,MatchEvent, orAnomalyDetection.aplQuery/mplQuery: Query evaluated by the monitor.notifierIds: Array of notifier IDs to notify.disabled: Whether monitor is disabled.disabledUntil: Optional timestamp for temporary disable/snooze.description: Optional monitor description.
Threshold and evaluation fields:
operator: Threshold comparison operator.threshold: Numeric threshold value.rangeMinutes: Query evaluation window in minutes.intervalMinutes: Evaluation cadence in minutes.alertOnNoData: Whether no-data should trigger alerting.triggerAfterNPositiveResults: Positive evaluations required before firing.triggerFromNRuns: Total evaluation runs considered for N-of-M logic.
Advanced behavior fields:
resolvable: Whether alerts can resolve automatically.notifyByGroup: Notify per group key/value result.notifyEveryRun: Notify on every positive evaluation.skipResolved: Skip sending resolved notifications.secondDelay: Delay (seconds) to tolerate late-arriving data.
Type-specific fields:
columnName: Field used by some anomaly/value-anomaly monitors.
Minimal Valid Monitor Examples
Threshold:
json{ "name": "High Error Count", "type": "Threshold", "aplQuery": "['logs'] | where status >= 500 | summarize count()", "operator": "Above", "threshold": 100, "rangeMinutes": 5, "intervalMinutes": 5, "notifierIds": ["notifier-id"], "triggerAfterNPositiveResults": 2, "triggerFromNRuns": 3, "disabled": false }
MatchEvent:
json{ "name": "Error Event Match", "type": "MatchEvent", "aplQuery": "['logs'] | where level == 'error'", "rangeMinutes": 5, "intervalMinutes": 5, "notifierIds": ["notifier-id"], "disabled": false }
AnomalyDetection:
json{ "name": "CPU Anomaly", "type": "AnomalyDetection", "aplQuery": "['metrics'] | summarize avg(cpu_usage)", "columnName": "cpu_usage", "operator": "AboveOrBelow", "rangeMinutes": 5, "intervalMinutes": 5, "notifierIds": ["notifier-id"], "disabled": false }
Minimal Valid Notifier Examples
Email:
json{ "name": "Oncall Email", "properties": { "email": { "emails": ["oncall@example.com"] } } }
Slack:
json{ "name": "Oncall Slack", "properties": { "slack": { "slackUrl": "https://hooks.slack.com/services/T.../B.../XXX" } } }
Custom webhook:
json{ "name": "Oncall Custom Webhook", "properties": { "customWebhook": { "url": "https://api.example.com/alerts", "body": "{\"action\":\"{{.Action}}\",\"monitorID\":\"{{.MonitorID}}\"}" } } }
Troubleshooting
401 Unauthorized:
- Cause: invalid or expired token.
- Fix:
- Verify token in
~/.axiom.toml. - Re-run
scripts/setupand retry:scripts/notifier-list <deployment>
- Verify token in
403 Forbidden:
- Cause: token lacks required permissions.
- Fix:
- Create/assign token scopes for monitor/notifier management and dataset query access.
- Retry:
scripts/monitor-list <deployment>
404 Not Found on get/update/delete:
- Cause: wrong monitor/notifier ID or wrong deployment/org.
- Fix:
- Confirm deployment in
.axiom.toml. - Re-list objects and use exact IDs:
scripts/monitor-list <deployment> --jsonscripts/notifier-list <deployment> --json
- Confirm deployment in
400 Bad Request on notifier create/update:
- Cause: invalid notifier payload shape.
- Fix:
- Use one notifier channel inside
properties. - For email, use
emails(notrecipients). - Validate against a known-good example and retry:
scripts/notifier-create <deployment> <json-file>
- Use one notifier channel inside
400 Bad Request on monitor create/update:
- Cause: invalid monitor schema, operator/type mismatch, or invalid query fields.
- Fix:
- Validate required fields:
name,type, query field, schedule, andnotifierIds. - Confirm
operatormatches monitor type and threshold logic. - Retry:
scripts/monitor-create <deployment> <json-file>scripts/monitor-update <deployment> <id> <json-file>
- Validate required fields:
Monitor created but never alerts:
- Cause: threshold too strict, wrong query window, or not enough positive runs.
- Fix:
- Inspect history over a known active period:
scripts/monitor-history <deployment> <id> <startTime> <endTime>
- Reduce threshold or widen
rangeMinutes. - Tune
triggerAfterNPositiveResults/triggerFromNRuns.
- Inspect history over a known active period:
Too many alerts (noisy monitor):
- Cause: threshold too low or interval too short.
- Fix:
- Increase threshold.
- Increase
triggerAfterNPositiveResultsand/ortriggerFromNRuns. - Increase
intervalMinutesor narrow match conditions.
Notifier exists but no delivery:
- Cause: destination config invalid (URL/key/channel/email list), or destination-side rejection.
- Fix:
- Fetch notifier and verify destination fields:
scripts/notifier-get <deployment> <id>
- Recreate/update notifier with corrected properties:
scripts/notifier-update <deployment> <id> <json-file>
- Confirm monitor references correct notifier IDs.
- Fetch notifier and verify destination fields:


