7 Commits

Author	SHA1	Message	Date
Niklas Ye	dc39e3a5d3	Move the database to Postgres, before teams need the schema ... First step of #1, and it goes first for one reason: #4 adds a team_id to nearly every table, and doing that twice -- once for SQLite, once for Postgres -- is work nobody gets paid for. The teams migrations now only have to be written against one database. The ten SQLite migrations are replaced by a single Postgres baseline rather than ported one by one. They were incremental in a way that has no value on a fresh install: 004 adds columns 008 drops again, and 008's backfill rewrites data a Postgres database never had. The history stays in git; the schema they add up to is now 001_baseline.sql. Timestamps stay BIGINT unix seconds and are NOT converted to timestamptz. Everything in Go already speaks epochs, so converting would have been a second, larger change riding along inside this one. It is worth doing on its own. The JSON columns did move to jsonb, because #4 will want to filter and index on labels. Most of the port is mechanical -- 170 placeholders from ? to $1 -- but four things needed more than a search and replace: * Dynamically built WHERE clauses cannot keep their numbering straight by hand, so they hand out placeholders through sqlArgs instead. A filter can now be added or reordered without renumbering anything. * SUM(resolved_at IS NULL) was SQLite counting a boolean as 0 or 1. Postgres has no sum(boolean), and this was breaking every dead man's switch -- silently, since the sweeper only logs. Now COUNT(*) FILTER. * unixepoch() became FLOOR(EXTRACT(EPOCH FROM now()))::bigint. The FLOOR is load-bearing: a bare cast rounds half up, so a row written at .6 of a second claimed a timestamp a second in the future and disagreed with the time.Now().Unix() the Go side stamps. * The unique-violation check matched SQLite's error text. It matches SQLSTATE 23505 now, so a renamed constraint cannot turn a 409 back into a 500. Tests need a real Postgres, because there is no in-memory Postgres the way there was an in-memory SQLite. Each test gets its own schema on a shared server -- cheaper than a database each, and still isolated. TERDUT_TEST_DSN says where it is; `make test-db` starts one locally and ci.yaml runs one as a service container. An unset DSN fails the suite rather than skipping it: a run that quietly tests nothing is worse than one that does not run. TestMigration_BackfillCarriesAckAndComments is deleted along with the migrations it replayed. What it protected -- an upgrade not losing acknowledgements and comments -- now belongs to scripts/sqlite-to-postgres.go, which is build-tagged so the SQLite driver stays out of the server binary. Both are meant to be deleted once this install has migrated. The chart loses the PVC, the data volume and the python backup sidecar, and requires database.dsnSecret.name: it provisions no database and cannot guess where the credentials live, so a render without it is meant to fail. Backups move to where Postgres actually runs. The other half of that -- the postgresql CR, the k8up pg_dump annotation and the network policy -- is a change to the wrapper chart in Ryuvia/charts and is not in here. Verified rather than assumed: the gate is green with -race against Postgres 17, govulncheck and gitleaks are clean, and the migration script was run end to end against a SQLite database built at the old schema and seeded in every table. Ids survive, so incidents keep their numbers and every foreign key still points where it did; the identity sequences are moved past the copied ids, and a webhook after the migration opened incident 12 rather than colliding at 1.	2026-09-20 10:44:12 +02:00
Niklas Ye	dc3879eca6	Serve a web UI for the incident queue, built for phones ... Whoever is on call gets paged on a phone, and until now the only ways to act on a page were the notification's Acknowledge button or a terminal. Tapping the notification itself opened /api/incidents/{id}, which a browser can only answer with a 401 in JSON. The server now serves a web UI at / covering the incident queue, each incident's alerts and timeline with every action on it, who is on call, the alert feed, and changing your own password. The notification link now points at /incidents/{id} in that UI. It is embedded in the binary and has no build step: plain HTML, CSS and ES modules under internal/web/static, served with an ETag per file and a CSP that allows nothing from any other origin. That is how rd-web is built. It avoids adding a node toolchain to the Dockerfile and the pipeline for a page this size, and it keeps the page on the same origin as the API, so no CORS is needed and nothing else has to be deployed. Paths without a file extension fall back to index.html, so a deep link survives a reload. An unknown path under /api/ still gets a JSON 404 rather than the page. Signing in uses a username and password, because pasting a 64-character API key into a phone at 3am is not a sign-in flow. Users have no password until one is set through PUT /api/users/{id}/password, or optionally at bootstrap. A user without a password is exactly where they were before this commit and can only use API keys. A login sets an HttpOnly, SameSite=Lax session cookie. It lasts 30 days and slides forward while in use, so an on-call phone does not sign itself out. Only the token's hash is stored, as for API keys. The cookie needs a CSRF guard where a bearer header does not, because browsers attach cookies to requests other sites make. So cookie- authenticated requests go through Go 1.25's http.CrossOriginProtection, and bearer requests do not. A request carrying an Authorization header is judged on that header alone and never falls back to the cookie. Changing a password ends every other session of that user. Changing your own requires the current password, so a phone left signed in cannot be used to take the account over. Failed logins are counted per username and per client address. Ten failures for one username in 15 minutes refuse that username for the rest of the window, even with the right password. That makes locking somebody out possible for anyone who knows their username. It was accepted because the alternative is unlimited guessing, and during a lockout the notification's Acknowledge button and API keys keep working. The address limit reads the first X-Forwarded-For hop, since behind the gateway RemoteAddr is Envoy. It is looser, because a whole office behind one NAT shares it. The Secure flag follows TERDUT_PUBLIC_URL, since TLS terminates at the gateway and the server itself only ever sees plain HTTP. The chart already defaults that variable to https://<hostname>. Schedule editing, statistics and user management stay in terdut-tui for now. The API they use is unchanged, and bearer authentication behaves exactly as before.	2026-09-19 17:48:21 +02:00
Niklas Ye	14c24f8fda	Notice when the Watchdog alert stops arriving ... Everything this server does assumes alerts arrive. If Prometheus stops evaluating, or Alertmanager cannot reach us, nothing arrives — and silence is indistinguishable from everything being fine. The cluster has shipped the alert for exactly this case all along: Watchdog is expr: vector(1), so it fires permanently and is re-sent forever, and it is worth nothing unless something downstream notices it stop. Nothing did. It arrived, opened no incident because a repeat_interval re-send is not a new occurrence, and when the monitoring stack died the sweeper quietly expired it and paged nobody. So the handling is inverted for a configurable set of alerts: receiving one opens no incident, and the absence of one does. TERDUT_DEADMAN_MATCHERS selects them as label matchers, defaulting to alertname=Watchdog. The unit of monitoring is the fingerprint rather than the alert name. Two clusters sending the same Watchdog are two independent switches, so a healthy one can never mask a dead one. Every matcher must name an alertname, which keeps the sweeper's candidate query on alerts_name_idx instead of JSON-extracting labels from every row, and leaves matching with a single implementation. A switch is dormant until its first heartbeat: a matcher nothing has ever sent opens nothing, so a fresh deploy or a restored database does not page. Resolving the incident by hand sticks, exactly as it does for an alert-backed one, so a decommissioned source is a one-time page rather than a nag; the switch re-arms only when the heartbeat comes back, and dying again is a new incident. The incident has no member alerts on purpose. Linking the heartbeat would have the settled-incident cascade close it on the very sweep that opened it, and there is no alert describing the problem anyway — the problem is that no alert arrived. What happened is on the timeline instead, and recovery is the only automatic way out. One narrow exemption in the ingest guard makes recovery possible at all. A heartbeat we declared dead is marked resolved, and the one that proves us wrong carries the unchanged startsAt of an alert that never stopped firing — so "resolution is terminal within an instance" would discard it forever and a switch could die exactly once. The exemption is scoped to resolution_source = 'deadman', which is the only resolution this server infers from silence on a timeout of its own, so nothing another writer set can be undone by a stale retry. Matched alerts are also held back from the generic staleness expiry, which would otherwise resolve a heartbeat as 'expiry' long before its own tighter deadline. The timeout points the opposite way to TERDUT_STALE_AFTER: staleness is a generous grace period around a repeat_interval you do not control, while this is a deadline you set deliberately and configure the heartbeat's route to beat. Inheriting a 4h or 12h repeat_interval gives a dead man's switch with a twelve hour fuse, so the README spells out the route the heartbeat needs.	2026-08-08 21:28:55 +02:00
Niklas Ye	bc285799d1	Page the on-call person when an incident opens ... An incident opened, got assigned to whoever held today's schedule entry, and then sat there silently until somebody thought to look. The schedule and the incident model were both built; nothing reached the person holding the pager. Notifications go out through ntfy, over plain HTTP with no new dependencies. Delivery is an outbox rather than an inline call: the pool is limited to a single connection, so a POST made while holding the webhook's transaction would stall every other request behind it. The webhook inserts a row and a notifier goroutine sends it within a tick, retrying with exponential backoff. Only opening an incident has to resolve a topic from scratch. Reminders and all-clears reuse whatever that first notification chose, which keeps configuration out of resolveIfSettled and gives the right rule for free: you only hear that something resolved if you were told it started. Each push carries an Acknowledge button, because the useful thing to do at 3am is stop the pager without unlocking anything. It POSTs to an unauthenticated /api/notify/ack/{token} — a notification body lives on the ntfy server and in the device cache, so a real API key must never appear in one. The token is minted per delivery, scoped to one incident and one action, and expires in a day. Reminders repeat until the incident stops being untouched. The stop conditions are the states that already mean somebody has it: acknowledged, snoozed, resolved, archived. Snooze is the mute button, so there is no separate reminder cap. Notifications sent to the fallback topic carry no Acknowledge button. The topic is shared, and a button on it would let any subscriber acknowledge as somebody else.	2026-08-07 08:51:38 +02:00
Niklas Ye	279ef6cf8b	Turn incoming alerts into incidents ... The alerts row was both Alertmanager's record and the human work queue, and the two have different owners. The webhook upsert rewrites that row on every notification; acknowledgement, comments and archiving were columns on it that the upsert happened not to touch. So an alert that resolved and re-fired days later still read as acknowledged by whoever acked the first occurrence — the ack outlived the thing it referred to. Nothing recorded transitions either: rows are mutated in place, so there was no timeline and no way to compute how long anything took. Alerts are now read-only signal records with two states, and incidents are the work item: triggered, acknowledged or resolved, with an assignee, a snooze, notes and an append-only timeline. Many alerts map to one incident, and a new occurrence opens a new incident, which is what makes a stale ack impossible rather than merely unlikely. Correlation uses Alertmanager's own groupKey. It already grouped the alerts according to the group_by routing tree the operator configured and sends the result on every webhook, where it was being discarded; adopting it means changing group_by in alertmanager.yml changes correlation here, with no second grouping scheme to configure and keep in sync. An incident opens only when an alert transitions into firing — an unseen fingerprint, a newer startsAt, or a resolved alert starting again. The unchanged notifications Alertmanager re-sends every repeat_interval are none of those. That rule is what lets manual resolution be terminal: without it, closing an incident by hand would be undone by the next re-send of an alert that never stopped firing, and the button would be a lie. Snooze covers the "not now" case instead. Incidents otherwise resolve by cascade, once every alert under them has stopped firing, whether by webhook or by expiry. New incidents are assigned to whoever holds today's schedule entry. The schedule table has existed since the first release with nothing reading it. Also here, following from the split: - Incident severity is a high-water mark over its alerts, never lowered. An incident that hit critical was a critical incident, and downgrading a live one would demote it in the queue while the work is still open. - /api/stats/incidents reports MTTA and MTTR, null rather than zero until there is something to average. Neither was computable before. - Alert archiving becomes sweeper-only housekeeping; the archive people interact with is the incident's. Breaking: the alert acknowledge, archive and comment endpoints are gone, and the alert object drops the acknowledgement fields and gains incident_id. The README maps each removed endpoint to its replacement. Migration 008 backfills an incident per existing alert, archived ones included so no comment is orphaned, carrying acknowledgements across and turning comments into timeline notes. Both documented alert contracts are untouched: received_at still advances on every accepted payload, re-sends included, and resolution_source still says how much to trust ends_at. The upsert is byte-for-byte what it was, now running inside the ingest transaction.	2026-07-30 17:02:13 +02:00
Niklas Ye	42e846f876	Expire stale firing alerts ... A resolved webhook was the only path out of the firing state, so a notification that was dropped, silenced, or lost to a restart pinned an alert as firing forever — Prometheus showed it resolved while terdut-server kept listing it. The archiver only ever touched resolved alerts, and both the list and stats queries compared status with plain equality, so a stale row was indistinguishable from a live one. A sweeper pass now resolves firing alerts on either of two signals: the ends_at watermark Alertmanager sets on outgoing firing notifications has passed (plus a grace period for clock skew), or no webhook has refreshed the alert within TERDUT_STALE_AFTER (default 6h, above Alertmanager's 4h repeat_interval). Such alerts get resolution_source = 'expiry', distinguishing them from a real 'alertmanager' resolve. Two related webhook bugs fixed alongside: - The upsert had no ordering guard, so a retried firing notification arriving after the resolved one resurrected the alert. Payloads for an older alert instance are now discarded: a stale retry carries the same startsAt, a genuine re-fire a newer one. - archived_at was never cleared on re-fire, leaving a re-fired alert archived and invisible in the default list. Stats now exclude archived alerts to match the default list view; this lowers historical firing/resolved totals. The chart exposes both sweeper durations via sweeper.staleAfter and sweeper.archiveAfter.	2026-07-28 11:49:39 +02:00
Niklas Ye	debc4bf78c	Add alert archiving ... Alerts can be manually archived (POST /api/alerts/{id}/archive) or unarchived (DELETE /api/alerts/{id}/archive). A background goroutine auto-archives resolved alerts older than TERDUT_ARCHIVE_AFTER (default 7d). GET /api/alerts hides archived alerts by default; ?archived=true shows them.	2026-05-22 13:22:45 +02:00