Atomic Limits and alerts

A function runs inside three declared bounds, and tells you when it crosses one. The bounds are the Driftfile's; the telling is an alert you define per function.

Limits, and what the caller sees

Three Driftfile knobs bound a function: function_timeout, function_memory and rate_limit. This is what a client gets when one is reached:

A timeout is enforced once, on one clock, so a call cannot be cut off in one place while still running in another. With no runtime limit declared the ceiling is 300 seconds, which stops a connection hanging indefinitely. The free tier resolves to 10 s of runtime, 32 MB per invocation and 60 requests per minute; a configured slice sets its own.

Alerts

The slice evaluates alerts once a minute against each function's error count over a sliding window, and fires a webhook on each state change: one POST when it starts firing, one when it resolves, not one per tick. Alert definitions survive a restart.

drift atomic alert add checkout-errors checkout \
  --on errors --threshold 5 --window 5m \
  --notify webhook=https://hooks.slack.com/services/…

drift atomic alert list
drift atomic alert remove checkout-errors

Or declare them alongside the function in the Driftfile:

atomic:
  functions:
    - name: checkout
      alerts:
        - { on: errors, threshold: 5, window: 5m, notify: "webhook=https://hooks.slack.com/..." }

on: errors and notify: webhook= are the whole surface. Other trigger and notify types are rejected when the alert is registered, not silently ignored. The window minimum is 60 seconds. The webhook receives JSON:

{
  "alert": "checkout-errors",
  "function": "checkout",
  "trigger": "errors",
  "transition": "firing",      // or "resolved"
  "threshold": 5,
  "window": 300,
  "at": "<RFC 3339 timestamp>"
}