Changelog

User sessions, authentication caching, rate limiting and related frontend state now run on a dedicated Redis instance, separate from the Redis instance that powers the monitoring job queues. This isolation ensures that heavy queue activity can never affect login sessions or dashboard responsiveness, and vice versa. Both instances run on our own infrastructure in Germany; no provider or data-location change is involved.

We introduced a per-monitor ownership class across all monitor types (website, DNS, ICMP, SMTP, SSH, FTP, IMAP/POP, domain expiry, DNSBL). Managed monitors keep today's behavior exactly: the organization runs them and the full escalation setup applies. Self-service monitors are owned by the customer: customer portal users can create, edit, and delete them within a package quota, and their alerts are delivered to the customer's own recipients only — organization-level integration channels (webhooks, OpsGenie, org SMTP) are skipped for them. All existing monitors were classified managed, so nothing changed for any running monitor until an organization explicitly enables self-service. The API gained the corresponding fields and a change-request flow; see the documentation for details.

The primary database powering Uptimeify has been migrated from a single-node container deployment to a Patroni-managed high-availability PostgreSQL/TimescaleDB cluster with automatic leader failover. Database provisioning and backups are now managed through a dedicated infrastructure-as-code stack (Ansible) instead of the application deployment pipeline, separating data-critical operations from routine application releases. All data remains hosted on our own infrastructure in Germany; no provider or data-location change is involved.

We consolidated the per-protocol check workers onto a single hardened check engine, rolled out to all monitoring locations. What this means for your monitors: identical security and reliability safeguards across every protocol (including SSRF protection and consistent connection-retry behavior), response times for SMTP/SSH/FTP/IMAP/POP checks now measure the protocol connection itself (DNS resolution time is no longer included, so values may read slightly lower and more consistent), and DNS monitors comparing long TXT records (for example DKIM keys over 255 characters) now match correctly instead of reporting false mismatches.

We deployed an updated monitoring worker release to all check locations. Highlights: maintenance windows now reliably suppress DNSBL (blocklist) notifications; DNSBL and domain-expiry alerts are delivered to all integration channel types (e.g. Telegram, Opsgenie, PagerDuty); redirect-loop failures are verified with a real browser before alerting and include screenshot evidence; plus a broad set of internal reliability and security hardening fixes across the check pipeline.

We now use fastmon (fastmon labs UG (haftungsbeschränkt), Germany) for real user monitoring (RUM). It collects performance and page-load telemetry from visitors of the Uptimeify web application so we can measure and improve front-end performance. fastmon does not process monitoring data — no monitored URLs, check results, or alert contents — and is hosted in Germany. It has been added to our subprocessor overview (German: /de/subprozessoren).

We now use Leadfeeder (Dealfront Group GmbH, Germany) for B2B website visitor analytics on our public website — it reveals which companies visit the site so we can support sales and marketing. It runs only after explicit cookie consent and never inside the monitoring application, and it does not process monitoring data (no monitored URLs, check results, or alert contents). It has been added to our subprocessor overview (German: /de/subprozessoren).

The product documentation has moved to a dedicated subdomain, docs.uptimeify.io, hosted on our existing EU application server (Hetzner). All previous documentation links at uptimeify.io/docs/… continue to work via permanent (301) redirects. No data processing changes and no new subprocessors — this is a reorganisation of how documentation is served, not where your data goes.

Our monitoring worker nodes previously performed website and service checks over IPv4 only. We have enabled IPv6 egress across our monitoring locations, so checks now use whichever address family a site publishes (dual-stack), matching how real visitors reach it.

For sites that publish an IPv6 (AAAA) address, this makes reachability results more accurate and avoids false "connection failed" alerts that could occur when a check attempted IPv6 from a location whose container networking was IPv4-only. No action is required on your side, and no data processing or third-party providers changed — this is an internal networking capability of our own monitoring infrastructure.

Our privacy policy previously listed Cloudflare as a CDN/:glossary-termDNS provider. Cloudflare is not part of our infrastructure, so the section was removed from both the English and German privacy policy. In the same review we clarified that our error tracking is self-hosted (Bugsink) on Hetzner servers in Germany — no error data leaves our own infrastructure.

We published a public subprocessor overview at /subprocessors (German: /de/subprozessoren). It lists every third-party provider involved in operating Uptimeify — including whether they process monitoring data and where they are located — plus the optional, customer-configured notification integrations. Future changes to our infrastructure or subprocessors will be announced through this changelog and its RSS feed.