Talaia

Talaia (Catalan): a coastal watchtower that spots trouble before it reaches the shore.

Talaia is a synthetic smoke-test monitor: a last line of defense against production breakage. Scheduled black-box tests exercise the most critical, most-used flows of each deployed app — login, create a record, complete a purchase — against the live deployment, and raise the alarm when something breaks.

Where an uptime checker tells you a port answers, Talaia tells you your users can still log in and get their work done.

What’s in the box

• Suites are plain pytest directories under projects/<project>/<suite>/ — API tests with httpx, browser tests with Playwright. No DSL.
• Scheduler: supercronic inside Docker, one cron line per suite (from each suite.yml).
• Storage: SQLite (WAL) — the single source of truth for runs, results and alert state.
• Alerts: Pushover on failure (after in-run retries), with a cooldown while down and a recovery message when green again. See Alerting.
• UI: a thin, UptimeRobot-style status page (FastAPI + Jinja, no JS build).
• Metrics: a Prometheus /metrics endpoint, plus an optional mirror to InfluxDB v2 for Grafana dashboards. See Metrics.
• Heartbeats: optional healthchecks.io ping per suite — a dead-man switch that alerts you if Talaia itself stops running.

Safety first

Talaia’s suites hit production on purpose, so the golden rules are non-negotiable: only ever use a dedicated test account, prefix created data with SMOKE- and clean it up, and put an explicit safety gate in front of any write flow. Flows that leave undeletable data belong in low-frequency suites, never in the every-10-minutes ones. Details in Writing a suite.

Where to go next

• Getting started — run Talaia locally in a couple of minutes.
• Writing a suite — suite.yml reference and conventions.
• Deployment — the two-container Docker Compose setup.
• Living Specs — the upcoming flagship: LLM-authored, self-healing browser tests (design stage).