Changelog

Our simple checks (HTTP, SSL, redirects) have always identified themselves with a SiteMonitorBot/1.0 (+https://uptimeify.io) User-Agent. The browser-based checks did not: screenshots and Playwright monitors arrived as an anonymous Chrome. In your access log they were indistinguishable from an ordinary visitor.

That is fixed. Two things changed:

The User-Agent. Browser-based checks now send a normal Chrome User-Agent with our token appended to it:

Mozilla/5.0 (…) Chrome/149.0.0.0 Safari/537.36 SiteMonitorBot/1.0 (+https://uptimeify.io)

We append rather than replace on purpose. A Playwright monitor walks a real user journey — a login, a checkout — and a great many WAFs block a bare bot User-Agent outright. If that happened we would report an outage your visitors are not experiencing. Keeping the browser shape avoids that; the token still makes us attributable.

A request header. Every check now also sends X-Uptimeify-Monitor: 1. This is the more reliable of the two, because a CDN or reverse proxy can rewrite a User-Agent. The value is a constant and never contains a monitor, customer or account identifier.

If you match on the User-Agent, match on the substring SiteMonitorBot — never the full string, which carries a Chrome version that changes with every browser update. Both signals are documented on Firewall allowlisting, alongside the node IP list.

Nothing you have configured needs to change. Existing IP allowlists keep working exactly as before — this only gives you two more stable things to filter on.

When we introduced email-based alert sources, we said the address you forward alert emails to would live on ingest.uptimeify.io. It now lives on alerts.uptimeify.io instead — an address looks like <token>@alerts.uptimeify.io.

Nothing about how the feature works changes: you forward an alert email from any tool that can send one, Lettermint (Netherlands, EU) receives it and hands the sender, subject and body to our platform over an authenticated webhook, and an incident is created exactly as it would be from a webhook alert. Lettermint's role and its entry on our subprocessor overview are unchanged.

The name is the only difference, and it is a clearer one: alerts. says what you send there.

Webhook alert sources are not affected. Zabbix, Datadog, Grafana, Prometheus Alertmanager, Sentry and custom webhooks continue to post to https://uptimeify.io/api/im/ingest/<token> on our main domain. Nothing to change on your side.

If you already hold an inbound address on the old domain, create a fresh email alert source to get one on the new domain.

We now use only the cookie-free variant of Leadfeeder (Dealfront Group GmbH, Germany) on our public website. It sets no cookies and does not access any information on your device, so it no longer depends on cookie consent. Your IP address is matched against a company database to determine which company is behind a visit, and is then truncated or discarded — identifying individual people is not the purpose.

The legal basis changes with it: the processing now rests on our legitimate interest under Art. 6 (1) (f) GDPR rather than on consent, and you can object to it at any time under Art. 21 GDPR. It still runs only on our public website and never inside the monitoring application, and it still processes no monitoring data.

The subprocessor overview (German: /de/subprozessoren) and our Privacy Policy have been updated accordingly.

We are adding two check locations to our European fleet: Berlin (DE) and Logroño (ES). Both run on IONOS Cloud, already listed as a subprocessor for check-node infrastructure, and both sit inside the EU. The fleet grows from seven locations to nine.

Spain is a new country in the fleet. Until now our checks originated from Germany, Finland, France, Italy and Poland; monitors that restrict checks to specific countries can now pick Spain as well, which matters most for Iberian endpoints where the nearest node was previously Paris or Milan.

If you allowlist our check nodes in a firewall, act now. The four new IPv4 addresses and their IPv6 counterparts are already published in uptimeify.io/ips.txt, deliberately ahead of the nodes taking traffic — that file is the authoritative list, and adding the addresses before checks start is what keeps a new location from looking like an outage on your side. If you keep a copy by hand, re-read it now.

Both locations appear on our status page as their own components, with their own availability and their own measurement coverage, once they begin serving checks.

Nothing about where your data is stored or processed changes: the platform stays hosted in Germany, and no new subprocessor is involved.

We have added IONOS SE (IONOS Cloud) to our subprocessor list. IONOS provides server infrastructure for monitoring check nodes — the same role Hetzner, OVH, netcup and UpCloud already fill.

The location is Germany, and therefore inside the EU. What runs across these nodes is monitoring data, meaning the check results of the systems you monitor; no content belonging to your end customers is stored there.

The full list is on the subprocessors page.

We have made the role description of netcup GmbH and UpCloud Ltd more precise in our subprocessor list. Both provide not only monitoring check nodes but also run Redis job queues and databases for us.

This is a clarification of what actually runs there, not a move: no new provider is involved, and the locations are unchanged — netcup in Germany, UpCloud in Finland, both inside the EU. Nothing about the processing changes for you; the entry is simply more complete than it was.

The full list is on the subprocessors page.

We ask you to trust a number we produce about your systems. It is only fair that the number we produce about our own is measured the same way — and visible to you without asking us for it.

What we measure. The figure is check delivery: the share of the check cycles our network was scheduled to run that it actually ran. Every monitor is due one check per check interval; that is one cycle. A cycle counts as delivered when at least one of our locations actually ran it, and a cycle that produced no check anywhere is the only thing that subtracts. Whole numbers, no shares, no averaging — the same shape as the uptime figure we compute for your own monitors, which counts observed time and only drops on a real failure. That is the work we owe you, so that is what we count; not whether our marketing site answered a request.

What this deliberately gives up. If one of our locations goes down, the scheduler redistributes its work to the others and the cycles still happen — so this figure will stay near 100% through a location outage. That is the correct trade. Losing a location is a real event and it is published directly, per location: each check location is its own component on the status page, with its own availability and its own measurement coverage. Inferring an outage from arithmetic is the weaker signal; measuring it is the stronger one.

Two numbers, not one. Availability is measured over the minutes we can account for. Next to it we publish measurement coverage: how much of the period that actually was. If the recording stops, if an aggregation does not complete, or if a component reports no state, those minutes are never assumed healthy and never quietly dropped — they lower the coverage figure. What they are not is downtime. "We were unavailable" and "we could not measure" are different statements, and reporting the second as the first would publish an outage that did not happen while turning the headline into a measure of our own recorder's reliability. Both figures are always shown together, including when coverage looks bad; multiply them for the conservative reading.

Alert delivery, in two numbers. Beside check delivery we publish how our alerting itself performed: the share of attempted deliveries that eventually got through, and the p90 time from an incident opening to the first notification that actually left our systems. Two numbers, because one cannot answer both questions — and a delivery that failed twice before succeeding counts once, as delivered, rather than being held against the retry that rescued it.

Whose failure it was. The delivery figure counts the failures that are ours. When an alert does not arrive because the receiving endpoint is gone, because the credentials you gave us were revoked, because your service rate-limits us or its host cannot be reached at all, that is a failure of that endpoint — scoring it against our alerting would turn the headline into a measure of everyone's webhooks rather than of our machinery. Those deliveries are not hidden: they are counted and published beside the figure as endpoint failures, so the two numbers together still account for every alert that did not arrive. Anything we cannot confidently pin on the far end counts against us, because the opposite rule would improve the number every time we found a new way to fail.

Nothing reaches back past the day we started measuring. Our notification records go back much further than our own measurement does. The alert figures do not use that history: they start where the "Measuring since" date on the status page starts, like everything else on it. For a while that means both alert numbers will say so instead of printing a value — which is the correct thing for them to say.

A figure appears when it means something. Check delivery is published once the measured series covers one hour, the alert figures once at least 20 events stand behind them. Below that the page names the threshold instead of printing a number: on a short series a single minute our scheduler missed moves the figure by a whole percentage point, which says more about the length of the series than about the network, and a percentage over a handful of events is noise dressed as precision. What stays visible either way is the date measurement began, the measurement coverage and the sample sizes — the things that explain the absence.

Announced maintenance is not excluded. A maintenance window in Uptimeify suppresses alerting, not scheduling — your checks really do run during one. So those checks count in our figure like any other, rather than being carved out the way availability numbers usually are.

Where to find it. The current trailing-90-day figure, the state of each published component and the monthly totals behind them are on our public status page, and in machine-readable form at uptimeify.io/api/service-status — no authentication, no customer data. When a month closes, its figures are frozen: the record can only be appended to, and each entry is hash-chained to the one before it. If you save today's response and a past month ever reads differently later, the hash will tell you.

One limitation we would rather state than hide. A cycle we missed can still be recorded as delivered if a check you triggered on demand through the API happens to land in the same window; nothing in the data separates the two origins yet. Confirmation re-checks — the ones we run from a second location to verify a suspected outage — do not have this effect, because they add no cycle and are recorded against the cycle they came from. We are labelling check origin at the source to close the remaining case.

The landing page previously showed a platform-uptime figure that was not derived from any of this. We removed it. It will come back when the measured series is long enough to stand behind, and it will be the measured one.

We have corrected the role description of seven communications GmbH & Co. KG (seven.io) in our subprocessor list. It read "SMS delivery" and named only SMS alert notifications. seven.io is also the provider that places our voice alert calls — it has been since voice alerting existed, and the entry that announced LOX24 as the secondary provider "for SMS and voice" in July already implied it.

This is a correction of an incomplete entry, not a change in processing. No new provider is involved, nothing moved, and the location is unchanged: seven.io is a German company. What seven.io receives for a voice call is what it already received for an SMS — the recipient's phone number and the content of the notification — and that is now stated on the entry.

The full list is on the subprocessors page.

We have removed Zeeg GmbH (Berlin, Germany) from our subprocessor list. Zeeg was the scheduling tool for demo, sales and onboarding calls booked through our website, and it processed the name, email address and meeting details of the person booking. We no longer use the service, so no data reaches it any more.

Nothing about the platform changes. Zeeg never had access to your account or to monitoring data — it supported our internal business operations only, and it is listed under that heading precisely so that distinction stays visible.

The full list is on the subprocessors page.

Trial accounts that never add a payment method are governed by a defined schedule, which we are switching on in stages: monitoring pauses 14 days after signup, a warning email goes out seven days before deletion, and the account together with its data is deleted 30 days after monitoring pauses — 44 days from signup in total — unless a payment method is added first. Adding one at any point, even mid-trial, takes the account off this schedule entirely, with no separate opt-out required.

The data export stays reachable for the whole period, including after monitoring pauses, so there is always time to save your data before deletion. Paying accounts are unaffected.

Every account that already exists today keeps a full 14 days from now, regardless of when it originally signed up — nobody is deactivated retroactively as this rolls out.

Until now you could export a single monitor's check history from its detail page. From today an administrator can export everything the organization holds in one go: customers, monitors of every type, incidents and incident updates, maintenance windows, notification channels, tags, status pages, reports and their run history, billing records, team members, API token metadata, incident-management configuration and history, and the raw check history behind your monitors.

The export is available in the dashboard under Settings → Data export and over the API (POST /api/organization/data-export). Every record is written twice — as JSON for a faithful re-import and as CSV for a spreadsheet — plus a manifest.json that lists each section with its row count, so you can verify completeness without opening a single file.

Two things bound the contents, and both are stated in the bundle itself. Time-series data reaches back as far as the data retention included in your packages — older rows are not withheld, they no longer exist. And credentials never leave the platform: passwords, webhook secrets, integration tokens, API token hashes and SMTP passwords are replaced with a redaction marker, while the surrounding record is exported in full.

Where the file lives: the ZIP is written to our object storage at Hetzner in Germany — the same storage that already holds report PDFs and branding assets, so no new provider is involved and your data does not leave the European stack. The download runs through an authenticated request that issues a five-minute link; the bucket itself is not browsable. Seven days after the export is built, the file is deleted automatically and the record is marked as expired. There is no extra charge for exporting, and you can request one export every six hours.

Uptimeify checks your monitors from several European locations and confirms every outage from more than one of them. Two of those locations have moved: the nodes in Zurich (CH) and Prague (CZ) have been retired, and new nodes in Frankfurt (DE) and Paris (FR) have taken their place. We also added capacity in Milan and Warsaw.

The fleet still spans seven European locations, all within the EU: Nuremberg, Falkenstein and Frankfurt in Germany, plus Paris, Warsaw, Milan and Helsinki. What changed is the country list — checks no longer originate from Switzerland or Czechia, and France joins instead. Nothing about this changes where your data is stored or processed: the platform remains hosted in Germany, and no new sub-processor is involved.

If you allowlist our check nodes in a firewall, you need to act. The retired nodes' addresses have been removed from uptimeify.io/ips.txt and the new ones added. That file is the authoritative list; if you maintain a copy by hand, re-read it now. Monitors that restrict checks to specific countries are worth a look too — a monitor pinned to Switzerland or Czechia has no location left to run from.

Uptimeify monitors its own production services with Uptimeify. A release swaps the application container, which takes a few seconds — long enough for our own checks to register a failed request and open an incident on the public status page for something that was planned all along.

From now on the deployment pipeline opens a maintenance window on those monitors right before the container is swapped, and removes it 30 seconds after the release is finished. During a release our status page therefore shows planned maintenance instead of an incident, and the availability figures for our production services no longer count our own deploys as downtime.

The window is deliberately short-lived and self-expiring: if a release fails or is cancelled, the window is lifted immediately so real alerts fire again, and even a pipeline that dies mid-run leaves a window that expires on its own. Nothing changes for your own monitors, your alerting, or how your data is processed.

Until now, every release of the Uptimeify web application was compiled on the application server itself. From today the image is built and verified in our CI runners first; the server only pulls the finished, version-pinned image and replaces the running container. Deploys are shorter, the maintenance window during a release is smaller, and the same verified artifact can be rolled out to more than one application server — the groundwork for running the app redundantly across multiple hosts.

At the same time we removed the last leftovers of the old single-server setup. The application database moved to a Patroni high-availability PostgreSQL cluster in July, and the queue and cache layer moved to a Redis Sentinel cluster shortly after. Both clusters run on separate hosts on our own EU infrastructure, reachable only over our private network. The unused local PostgreSQL and Redis containers on the application server have now been shut down, so the application host no longer stores customer data at all.

Everything stays on our existing European infrastructure. No new subprocessor, no change to how your data is processed, and nothing to do on your side.

AI agents that register with Uptimeify's agentic-registration authorization server (https://uptimeify.io) can now be claimed: while signed in, you authorize a specific agent, either one that started a claim ceremony directly (service_auth) or an existing anonymous registration upgraded via POST /agent/identity/claim, by confirming a short code on the /claim page. Once confirmed, the agent receives a read-only access token scoped to your organization, or to a single customer if your role is restricted to one. A claimed agent can read websites, incidents, and health status. It can never create, modify, or delete anything. You can revoke a claimed agent's access at any time via the existing token-revocation endpoint. See the API docs, "Agentic registration → Claim flow", for the full ceremony. No new third-party providers or subprocessors are involved.

Uptimeify now shows every application you've connected via OAuth (for example Claude connected to /mcp) under Settings → Connected applications, where you can revoke access at any time. Revoking disconnects the application right away (it can no longer read your data) and requires fresh approval to reconnect. Each connection is read-only and scoped to your own account. No new third-party subprocessor is involved.

The Model Context Protocol server at https://uptimeify.io/mcp now includes authenticated, read-only tools. By sending an Uptimeify API token as an Authorization: Bearer header, an AI agent can list your website monitors, read a monitor's current status, list recent incidents, fetch check history, and get an uptime summary. Access is scoped exactly like the REST API: a customer-scoped token sees only its own customer's data, an organization token sees the whole organization, and all tools are read-only. No new data processing or third-party providers are involved.

Uptimeify's /mcp endpoint (used by Claude and other MCP-compatible clients) now supports standard MCP OAuth (OAuth 2.1, PKCE, and Dynamic Client Registration) in addition to static API tokens. Connecting via OAuth grants only read-only access to your own monitors, incidents, and status pages, scoped to exactly the same visibility your account already has, and it can never create, edit, or delete anything. No new third-party subprocessor is involved; this runs on our existing application and database infrastructure.

Uptimeify now operates a same-origin, WorkOS-style agentic-registration authorization server at https://uptimeify.io. AI agents can discover it via /.well-known/oauth-authorization-server and /.well-known/oauth-protected-resource, register anonymously at /agent/identity, exchange a signed identity assertion at /oauth2/token for a short-lived opaque access token, and revoke it at /oauth2/revoke. Agent access tokens are hard-gated to read-only GET/HEAD requests on an explicit allowlist and cannot perform any write. The signing key is an environment-provided Ed25519 key; if it is absent the feature stays fully off. No new third-party providers or subprocessors are involved.

We added two subprocessors that support our internal business operations. easybell GmbH (Berlin, Germany) provides our business telephony: the SIP trunk and cloud PBX behind our company phone line. Zeeg GmbH (Berlin, Germany) is the scheduling tool used to book demo, sales and onboarding calls via our website; it processes the name, email and meeting details of the person booking. Both providers are based in the EU (Germany) and are engaged under a data processing agreement. Neither has access to your account or monitoring data. Both are listed on our Subprocessors page.

AI agents can now use Uptimeify's free check tools directly over the Model Context Protocol (MCP). A stateless MCP endpoint at https://uptimeify.io/mcp exposes around twenty anonymous, read-only tools: SSL/TLS inspection, DNS and mail-deliverability checks (SPF, DKIM, DMARC, MX), HTTP header and redirect analysis, WHOIS, blacklist and reachability checks. Agents can discover the server through the MCP Server Card at /.well-known/mcp/server-card.json. No account or authentication is required for these tools.

To broaden the infrastructure our checks run from, we added two EU cloud providers that host additional monitoring check nodes: netcup GmbH (Germany) and UpCloud Ltd (Finland). Because check nodes see the hostnames of monitored targets and their results, both are now listed on our subprocessors page. Both operate within the EU; your monitors, data, and alerting are unaffected.

The internal queue and cache layer that drives check scheduling, alert and notification delivery, reports, and short-lived caching previously connected to a single Redis instance: a single point of failure for that part of the pipeline. We moved it behind a Redis Sentinel cluster spread across three nodes on our own EU infrastructure: Sentinel continuously monitors the primary and, if it becomes unavailable, promotes a replica and reconnects the workers automatically, so monitoring and alerting continue without manual intervention.

This is an internal reliability change: it stays fully self-hosted on our existing Hetzner infrastructure, adds no new third-party subprocessor, and requires nothing from you. Your monitors, alert channels, and data are unaffected.

Our monitoring nodes resolve the hostnames they check through local caching DNS resolvers on our own Hetzner infrastructure, which forward to unfiltered public resolvers only as a fallback: used when our own primary resolvers are momentarily saturated.

We have replaced Quad9 (a non-profit foundation based in Zurich, Switzerland) with DNS.SB, operated by xTom GmbH in Germany, so this secondary fallback now sits entirely within the EU. DNS.SB is an unfiltered resolver that keeps no query logs, so no legitimate monitored domain is ever blocked and no resolution data is retained. DNS4EU remains in place as our other EU fallback.

Because a fallback resolver may receive the hostnames of monitored targets, DNS.SB is now listed on our subprocessors page in place of Quad9. Resolution otherwise stays on our own infrastructure, and DNS blocklist (DNSBL) checks continue to resolve without any third-party forwarder.

We added an email-based alert source: customers can forward an alert email from any monitoring tool that emails alerts (a legacy on-call system, a vendor with no webhook option, an internal script) to a dedicated @ingest.uptimeify.io address, and it is turned into an incident the same way a webhook alert is.

Lettermint (Lettermint B.V., Netherlands, EU) — already our provider for outbound transactional email (alert notifications, reports, account emails) — now also processes this INBOUND traffic. When an email arrives at a customer's ingest address, Lettermint receives it and forwards its content (sender, subject, and body) to our platform over an authenticated webhook. No new provider was introduced; this is an expanded role for an existing one, and Lettermint remains EU-based (Netherlands) for both directions.

Lettermint's entry on our subprocessor overview (German: /de/subprozessoren) has been updated to reflect this expanded role.

SMS and voice calls are the last line of alerting — they reach a human when email and chat don't. Until now both ran through a single provider, seven.io. That made the loudest part of our alerting depend on one vendor being available at exactly the moment it matters most.

We added LOX24 (LOX24 GmbH, Germany) as a secondary provider for SMS and voice alert notifications. It runs on cold standby: every message goes out through seven.io first, and LOX24 is only used when seven.io cannot deliver. Two independent carriers, two independent failure modes — that is the entire point.

To send an SMS or place an alert call, LOX24 receives the recipient's phone number and the text of the notification. Nothing else is passed to it, and it is not involved in any other part of the platform. LOX24 GmbH is a German company, and a data processing agreement (AVV under Art. 28 GDPR) is signed. It has been added to our subprocessor overview (German: /de/subprozessoren).

Every monitoring node resolves the hostnames it checks through local caching DNS resolvers that run alongside the workers on our own Hetzner infrastructure. No third-party resolver sees which domains we monitor. Under a burst of concurrent checks these resolvers could briefly hit their capacity ceiling and return a transient "temporary failure in name resolution" (EAI_AGAIN), which a couple of checks read as the target being unreachable, even though the site was up and resolved fine seconds later.

We raised the resolvers' concurrency headroom so bursts are served from the local cache instead of failing, and widened the workers' own DNS retry window so a sub-second resolver blip is absorbed before a check is ever recorded as failed. A genuinely unresolvable domain still fails fast and alerts as before. No providers were added or changed: resolution stays entirely on our infrastructure.

Our monitoring nodes resolve the hostnames they check through local caching DNS resolvers on our own Hetzner infrastructure, which forward to upstream recursive resolvers. Previously that forwarding relied on a single upstream provider, so a brief saturation there could surface as a transient resolution failure and, in rare cases, a false downtime alert even though the site was up.

We added two independent, privacy-focused and unfiltered public resolvers as fallbacks: DNS4EU (the EU public resolver initiative, operated within the EU) and Quad9 (a non-profit foundation based in Zurich, Switzerland). We deliberately use their unfiltered variants so no legitimate monitored domain is ever blocked. Because these resolvers may receive the hostnames of monitored targets, both are now listed on our subprocessors page. Resolution otherwise stays on our own infrastructure, and DNS blocklist (DNSBL) checks continue to resolve without any third-party forwarder.

We added a dedicated TCP Port monitor type. Point it at any host and port and we check, from our European monitoring fleet, that the port accepts a TCP connection within your timeout, optionally matching an expected substring in the service's first response (its banner). No credentials are involved.

We also added a "port only" check mode to the existing SSH, SMTP, FTP and IMAP/POP monitors. In this mode the monitor performs the same bare TCP reachability check instead of a full protocol handshake or login, so you can watch a service's port without configuring any credentials. The default "protocol" mode (full handshake/auth) is unchanged for every existing monitor.

Checks run from the same monitoring nodes and alert pipeline as our other service monitors: no new subprocessors or data-processing changes.

Our CI/CD pipelines now run on Ubicloud managed GitHub Actions runners. Ubicloud processes our source code and build secrets during a run: no customer monitoring data.

We contract with the Dutch entity Ubicloud B.V., but its parent Ubicloud, Inc. is US-based (San Francisco), so a US access path can't be fully excluded: covered by SCCs. Added to our subprocessor overview (German: /de/subprozessoren).

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/DNS 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.