Aurabase Logo
aurabasedocs
docs›Edge Functions›Alerts

Alerts

How to be told when your functions misbehave: the metrics you can watch, how rules are checked, and how to manage them over HTTP.

5 min read·Level intermediate·Revised on Oct 12, 2026
This English text was generated automatically from the French original and has not been reviewed yet.
#
Create

1. Create a rule

Alert rules are managed over HTTP with a service_role key. The SDK has no method for them.

terminalbash
curl -X POST "$AURA_URL/v1/functions/alerts" \
  -H "apikey: $AURA_SERVICE_ROLE_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "High error rate",
    "metric": "error_rate",
    "condition": "gt",
    "threshold": 5,
    "channel": "email",
    "destination": "oncall@example.com"
  }'
responsejson
{
  "data": {
    "id": "3356d54a-ed32-49df-84bf-94ee64790c78",
    "name": "High error rate",
    "metric": "error_rate",
    "condition": "gt",
    "threshold": 5.0,
    "channel": "email",
    "destination": "oncall@example.com",
    "enabled": true,
    "last_triggered_at": null,
    "created_at": "2026-10-12T15:42:34.721256Z"
  },
  "meta": null
}
#
Reference

2. Metrics, conditions and channels

FieldAllowed values
metricerror_rate, latency_p95, job_failures, low_disk, ai_quota, anomaly_detection, or log_pattern:<service>:<regex>
conditiongt, lt, eq, match, auto
channelemail, webhook, slack
thresholdA number
destinationAn e-mail address, or the URL of the webhook or Slack hook

log_pattern watches the logs of one service for a regular expression: log_pattern:functions:timeout. An unknown value returns 400 and lists the accepted ones. Real answer for metric: "cpu":

errortext
Requête invalide : Métrique inconnue: 'cpu'. Valeurs: error_rate, latency_p95, job_failures, low_disk, ai_quota, anomaly_detection, log_pattern:<service>:<regex>
#
Behaviour

3. How rules are checked

  • The service checks every enabled rule once per minute.
  • Numeric metrics are read from Prometheus; log_pattern rules query Loki. Each query has a 5-second limit. If one project fails, the others are still checked.
  • When a rule fires, the service sets last_triggered_at, records an event and publishes it for delivery on the chosen channel.
  • A rule you disable is kept but not checked.
Delivery depends on your deployment

Alerts need Prometheus and Loki to be reachable from the functions service, and the e-mail channel needs an e-mail provider. On a development stack without them, a rule is stored but cannot fire.

#
Operate

4. Manage rules and history

ActionRequest
List rulesGET /v1/functions/alerts
Enable or disablePATCH /v1/functions/alerts/{id} with {"enabled": false}
DeleteDELETE /v1/functions/alerts/{id}
History of one ruleGET /v1/functions/alerts/{id}/events
History of all rulesGET /v1/functions/alerts/events

An event has alert_rule_id, event_type, triggered_value, message and created_at; the history routes accept limit and offset. Every route needs a service_role key.

Last updated · Oct 12, 2026