Alerting

Talaia alerts through Pushover. Configure PUSHOVER_TOKEN and PUSHOVER_USER; with no Pushover credentials configured, alerts are logged to stdout only (handy locally).

Semantics

• A run fails only after exhausting its in-run retries (default: 1 retry after 30 seconds) — this kills most false alarms from transient network blips.
• up → down: one high-priority Pushover alert (priority 1) listing the failing tests and the first error lines, with a link back to the status UI (TALAIA_PUBLIC_URL).
• While down: re-alert at most every alert.cooldown_minutes (default 60, set per suite in its suite.yml). Repeat alerts show how many consecutive failures the suite has accumulated.
• down → up: a recovery message.

If a suite declares a version_url, the monitored app’s deployed version is fetched after each run and tagged on runs and alerts — so an alert can answer “which deploy caused this?”.

Missing configuration is an error, not a silent skip

Env vars listed in a suite’s env.required that are unset on the server cause the run to be recorded as error — visible in the UI and metrics — rather than the suite quietly testing nothing.

Heartbeats (dead-man switch)

Alerting on failures only helps while Talaia itself is running. For each suite you can set heartbeat_env in suite.yml to the name of an env var holding a healthchecks.io ping URL. After every run Talaia pings it — the plain URL on a pass, the /fail endpoint on a failure — so healthchecks.io pages you if the pings stop arriving (scheduler dead, host down, cron misconfigured), not just when a check goes red.