What's new

A human summary of each release — what changed and why. The full technical list lives in the CHANGELOG, announcements in the Telegram channel.

0.22.0–0.31.0 · August 27 – September 2, 2026 — project overview, typed keys and hardening

Ten releases in a week: a new way into a project, exports, typed ingest keys, secret key rotation and a long reliability pass over alerting.

• Overview screen and new navigation (0.29.0, 0.30.0). A project now opens on an Overview: a status line (uptime, hosts over threshold, new issues today), open incident groups and deploy markers — instead of dropping straight into the issue list. An organization gets an “All projects” screen in the organization/project switcher, and signing in without a remembered project lands there. The sidebar is split into three tiers (work areas, setup, footer), sections are named after their contents (“Transactions” is now “Performance”, “Performance issues” is “Bottlenecks”), and no page changed its URL. Issue bulk actions moved into a toolbar above the table; inputs and selects share one height in both themes.
• Error and event exports (0.22.0–0.24.0). A background CSV/JSON/NDJSON export of a project’s error groups or raw events, filtered by time range and environment. PII is masked by default — now including stacktrace, breadcrumbs, user_id (a stable per-export pseudonym) and free text; raw exports are for org admins and owners only. The set of matching groups is snapshotted before reading, so a group that gets a new event mid-export can no longer be skipped. Metadata left the file bodies (?meta=1, attributes on the page, a line in the email) — files open with standard tools again.
• Typed keys and the /api/v1 namespace (0.26.0, 0.27.0). DSN keys now have a type — browser, server or agent — with exactly the rights their source needs; a new project gets three keys right away, and a host registers only through an agent key. Keys issued earlier keep working unchanged. Logs, pprof profiles and deploy markers are accepted at POST /api/v1/logs, /api/v1/profiles/pprof and /api/v1/{project}/deployments; the old paths still work, answer with a Deprecation header and are counted by gotcha_ingest_deprecated_path_total — removal in 1.0. OTLP and Sentry-compatible endpoints are untouched.
• Secret key rotation (0.25.0). GOTCHA_SECRET_KEY_PREV lets you change GOTCHA_SECRET_KEY without losing SSO client secrets, channel tokens and monitor headers: old key next to the new one, restart — everything readable is re-encrypted. Values carry a format version and key id (enc:v2:<key-id>:...), so a rotation can be verified right in the database. The backfill runs on every start and picks up values left in plain text since the dev-key days. Roll forward only: once the first enc:v2 value is written, downgrading below 0.25.0 is not supported, and during a rolling deploy key rotation must wait until every instance is upgraded.
• Hardening (0.23.0, 0.28.0). docker-compose.yml listens on 127.0.0.1 by default — plain HTTP and the unauthenticated /metrics no longer face the internet past the HTTPS proxy (GOTCHA_BIND=0.0.0.0 restores the old behaviour). HSTS is configurable via GOTCHA_HSTS_*. Two unbounded-memory paths in the login-form rate limiters are closed: key length and request bodies are capped, every limiter has a hard cap on distinct keys, and the per-IP check runs before the per-account one. A new “Hardening your install” documentation page: reverse proxy, service endpoints, TLS/HSTS, security.txt and a curl self-check.
• Alerting reliability (0.23.0). Uptime monitors take part in escalation and can be acknowledged, like every other source. A failed “down” delivery is retried on the next check (up to five attempts), and with a dead channel the incident carries a “notification not delivered” badge. Recovery goes only to the channels that received the alert. Notifications name the project in the subject, body and webhook payload. A heartbeat is not credited to link previews and prefetchers — forwarding a URL into a chat no longer silences an alert. The log quota is editable in organisation settings.
• Self-metrics and configuration canon (0.23.0, 0.24.0). New metrics: ingest rejections by reason and signal, key rejections, liveness and tick duration of every evaluator, missing translation keys, ignored heartbeats. Breaking: queue metrics follow the gotcha_<subsystem>_queue_* scheme, and ten environment variables carry their unit or the right subsystem prefix (GOTCHA_RETENTION_DAYS → GOTCHA_EVENT_RETENTION_DAYS, GOTCHA_METRIC_EVAL_INTERVAL → ..._SECONDS and so on) — the old names are not read, and a start with one of them fails naming the replacement. The full table is in CHANGELOG 0.24.0.
• Flamegraph zoom (0.31.0). Every frame is a link: a click expands it to full width, ancestors stay on top as the way back, the “all” row restores the full profile. The zoom lives in the URL (focus=) and can be shared. Labels are tied to the row height and clipped inside their frame — no more text spilling out on tablets and phones.
• Also. Deleting a project deletes its logs from ClickHouse; subject data export/erasure and the backup instructions now cover logs. A layout pass at 360px: page titles, the event-frequency chart, context cards, the public status page, the SDK setup sample. The PostgreSQL connection pool has explicit bounds; stale-data cleanup also runs at startup; a failed ClickHouse migration no longer blocks rolling the version back. Documentation pages for escalation ladders and dependency-based alert suppression.

0.21.0 · August 26, 2026 — incident groups

• A cascade collapses into one card. When a node that others depend on goes down, the signals used to arrive from every direction: hosts behind the gateway fall silent, metric thresholds fire, a monitor’s SLO burns. Now a root availability incident (a silent host or a down uptime monitor) gathers its members around it — incidents of dependent hosts, monitors, host-scoped metric alerts and uptime SLOs. While the root is informing, members stay quiet and do not escalate, and the root’s notification carries a “Dependent nodes: N” line. Once the root recovers, the released members notify again and the escalation ladder restarts from the moment the group closed rather than from their own beginning.
• The root is decided by the facts, not by the order of events. A failure travelling top-down is grouped correctly too: when a node goes silent under an already-down parent, its children’s earlier incidents still join the top root’s group — even when that root is itself a monitor.
• Incident feed (under “Alerts”). One page for open groups with expandable composition, out-of-group incidents across all six sources, and everything that resolved in the last 24 hours. The composition shows who is quiet because the root is informing and who is suppressed by an unreachable parent — two distinct states that can coincide. An incident that outlives its group shows up among the ungrouped ones right away, pointing back to the group it came from.

0.18.0–0.20.0 · August 20–21, 2026 — service recipes

• Service monitoring recipes (0.19.0, 0.20.0). Ready-made recipes for PostgreSQL, nginx, Redis, Docker and MariaDB: an OpenTelemetry collector config, live-data detection, preconfigured charts and one-click recommended thresholds — useful monitoring for a service without writing alert rules by hand.
• Dependency-aware alert suppression (0.18.0). Hosts and monitors can declare dependencies: when a parent fails, its children’s alerts are silenced automatically — one notification instead of a storm, with a settling grace period and storm-free recovery.

0.13.0–0.17.0 · August 19–20, 2026 — smarter alerting

The close of the August sprint: fewer false alarms, more control over who gets notified and when.

• Notification escalation (0.17.0). A ladder of steps per severity: each step widens who gets notified after a configurable delay from when the incident opened — the same for hosts, metrics, regressions and SLOs. Acknowledging an incident stops the escalation; every incident shows a severity badge. The new Escalations screen configures both ladders with a dry-run preview.
• Project-wide maintenance windows (0.16.0). A window now silences notifications from every source — uptime, hosts, metrics, regressions, profiles, SLOs and error alerts — not just monitor checks. Windows can be open-ended for maintenance of unknown duration. Data collection and incident tracking are unaffected.
• Seasonal baseline for the regression detector (0.13.0). The detector can compare a metric against the same window on the same weekday over prior weeks — services with a pronounced daily profile stop ringing on the morning ramp-up. Falls back to the rolling baseline automatically when seasonal history is short.
• Host labels and threshold overrides (0.14.0, 0.15.0). Hosts carry an environment and a role straight from telemetry, with facet filters and grouping. Each of the four built-in thresholds can be overridden per host or per label group: a host → role → environment → project cascade with inherit / override / off at every level.

0.10.0–0.12.1 · August 18–19, 2026 — SLOs and deploy context

• SLOs and error budgets (0.12.0). A service level objective — availability, latency or uptime — on a rolling 1–90 day window. A two-window burn-rate alert opens an incident only when both the long and the short window burn the budget above the threshold. The SLO screen shows attainment, remaining budget, a burn chart and incident history.
• Deployment markers (0.11.0). CI reports a release with a single request; deployments show as version-labelled markers on the charts, and a regression that starts within 7 days of a release gets an “after deploy vX” note — the likely culprit is visible at a glance.
• Dependency map (0.10.0). A service’s external dependencies — databases, caches, outbound HTTP calls — with call volume, p50/p95 latency and error rate. Derived from the traces you already collect, no setup required.

0.7.0–0.9.0 · August 18, 2026 — logs

The third telemetry signal: logs are ingested, stored, searchable and cross-linked with everything else.

• Ingest (0.7.0). OTLP/HTTP (POST /v1/logs) and newline-delimited JSON (POST /logs), authorized with the project key. Severity is canonicalized to a six-level scale; logs get their own monthly quota and retention, and the body passes the same URL scrubbing as error messages.
• Logs screen (0.7.0). Time, severity, service and environment filters, full-text search, a volume histogram, facets with counts, attribute filters with autocomplete, “show older” pagination.
• Cross-linking (0.9.0). “Logs around this event” on an error page, “logs for this trace” on a waterfall, “host logs” on a host card.

0.5.0–0.6.2 · August 14–17, 2026 — host monitoring and the native agent

• Hosts section (0.5.0). System metrics for your servers — CPU, memory, disk, network, load average, process count — kept separate from application metrics. Four built-in thresholds (disk, memory, load, went-silent) open incidents out of the box; onboarding hands you a ready-made collector config with the key already filled in.
• Native gotcha-agent (0.6.0). A single dependency-free binary installed with one command served by your own instance — works in closed networks with no outbound internet. Runs as an unprivileged systemd service and buffers about an hour of undelivered metrics. The OpenTelemetry Collector remains a fully supported alternative.
• Security (0.5.1). Rebuilt on Go 1.26.6, closing seven Go standard library vulnerabilities.
• Self-contained builds (0.6.2). Go modules are vendored: the image build no longer reaches the internet, make up-rebuild works in air-gapped networks.

0.4.12 · August 12, 2026 — operator tier for teams

A cumulative release (includes the docs-only 0.4.11). The full story is in the blog.

• Operator tier. Project team members run day-to-day monitoring without org-admin rights: monitors, the heartbeat ping token, maintenance windows, status-page content, issue alert rules and metric alerts. Alert channels stay owner/admin: a channel’s recipient and secret are credentials, not an operational setting; the team sees the channel list and delivery log with recipients masked.
• Security. Monitor headers (e.g. an Authorization header on an HTTP check) are encrypted at rest, the same way channel secrets are. A status page’s public address is an opaque /status/p_... key instead of a slug: names can no longer be probed or squatted; old links keep working via 301.
• Reliability. Ingest: memory protection while ClickHouse is idle, honest queue/quota accounting, per-org attribution of dropped data. A corrupted channel secret is no longer treated as live — alerts are not lost on that path. Fixes for uptime check consensus, maintenance windows and OAuth invitations.
• UX. A Copy button on event pages — the event context on the clipboard in one click, as Markdown or plain text.
• Docs. The SDK section covers the CMS extension family (WordPress, Joomla, 1C-Bitrix, Drupal, OpenCart, MODX, Tilda); an AlmaLinux/RHEL installation guide.

0.4.10 · August 5, 2026 — stabilization of the 0.4.x line

The outcome of two full product audits (operations, security, accessibility, i18n) and the 0.4.5–0.4.10 patch train:

• Operations. Compose stack with memory ceilings and healthchecks; a hardened app container (read-only FS, no-new-privileges). Liveness and readiness are separate: /healthz and /readyz. --migrate-force recovers an interrupted migration; the schema carries a backward-compatibility marker — rolling back a release no longer requires restoring from a backup. Retention is configurable per data kind: metrics, profiles, incidents.
• Restricted networks. GOTCHA_TELEGRAM_API_BASE points Telegram delivery at your own Bot API server; GOTCHA_NET_MTU sets the container network MTU for tunnel setups.
• Correctness. Transaction quota is charged for what is stored, not what arrived; regression durations fixed (µs were read as ms); alerts, retries and throttling are computed by the database clock.
• Security. Removing a member from an organization revokes their teams' project access too; invite-mode registration requires the token from the link; deeply nested OTLP/JSON is rejected; the redirect guard is hardened (CodeQL report).
• Notifications & UX. One operator-chosen notification language (GOTCHA_LOCALE); “inside the perimeter” channels with full event details; keyboard navigation, contrast and screen-reader support across the UI.

0.4.0 · July 27, 2026 — time windows and explainable perf issues

• One time-range control (1h / 24h / 7d / 30d / custom) on every chart page.
• A perf-issue page explains “what’s happening / how to fix” for its kind (N+1, slow query, HTTP flood) — with the full SQL and the code location.
• Full request details on issue pages: method, URL, params, body, headers (PII-scrubbed).
• Tooltips for every metric: p50–p99, failure rate, Apdex, Web Vitals.

0.3.x · July 24–25, 2026 — reliable uptime and small servers

• Per-check retries for uptime monitors — transient blips no longer raise false incidents.
• Latency chart with DNS → TCP → TLS → TTFB phases; a distinct “partial” availability state.
• A docker-compose.small.yml overlay for minimal servers (2 vCPU / 2 GB).

0.1.0 · July 22, 2026 — first public release

The initial set: errors (Sentry SDK protocol), distributed traces and Web Vitals, OTLP metrics, CPU profiles (flamegraphs), uptime monitoring with status pages, alerts via email/webhook/Telegram, organizations and RBAC, SSO (OIDC, Yandex ID, VK ID), PII scrubbing and SSRF protection on by default — one Go binary with PostgreSQL and ClickHouse.