Open-source alternative to Datadog Synthetic Monitoring

The flow starts with the check runner, not the alert. In a self-hosted design, an Uptime Kuma instance inside the network runs each monitor (HTTP(s), keyword, JSON query, TCP, ping, DNS, push or Docker container) on its own schedule and records the result. When a monitor changes state, Uptime Kuma sends the notification through one of its more than 90 notification services, such as SMTP email, Slack, Discord or Pushover. A status page, mapped to its own domain, publishes the public or private view. Confirm whether your chosen status page updates on its own when a monitor fails or whether an operator must post the incident by hand, because that decision sets your response time during an outage.

Private locations, the self-hosted equivalent of Datadog's managed test locations, come from placing a probe inside each network segment that must be tested, then sending results to one central instance. With Uptime Kuma, the simplest pattern is one instance per segment, with the central team reviewing status from each. With Zabbix, proxies deployed in each segment collect data locally and report to the central Zabbix server, and proxy groups can redistribute hosts if a proxy goes offline. Decide early which segments need their own probe, since each probe is a server you patch, back up and monitor.

Multi-location checks are where the tools differ most, so confirm the behavior before you migrate any Datadog Synthetic test. Ask whether the tool runs one check from several vantage points and compares the results, and how it separates a failing service from a failing probe. A probe that loses its connection to the central instance must not appear as an outage for every application it watches. Also confirm where credentials for scripted browser steps are stored and who can read them. A short proof of concept with one internal application and one external endpoint will answer these questions faster than the documentation.

The cost of self-hosting synthetic monitoring is not a single line item, so start by separating what you pay today from what you would pay to run it yourself. On the Datadog side, the billing unit is the run: Datadog's pricing list shows Synthetic API tests at $5 per 10,000 test runs per month billed annually ($6 month-to-month, $7.20 on demand) and browser tests at $12 per 1,000 runs billed annually ($15 and $18). Those rates scale with check frequency and the number of locations, so pull your current run counts from the Datadog usage page before you compare. Self-hosted Uptime Kuma is MIT licensed and carries no license fee, and Zabbix has no license fee, device limits or feature gates. The costs that remain are the ones you must budget for explicitly.

The recurring costs are hosting, staff time and any paid support. Hosting covers the virtual machines or containers for Uptime Kuma or Zabbix, the database Zabbix requires (MySQL or Percona, MariaDB, or PostgreSQL with optionally TimescaleDB), storage for results, and, for browser scenarios, the worker capacity that runs a headless browser. Staff time is usually the largest recurring item: someone patches the platform, upgrades it on the Zabbix or Uptime Kuma release cycle, reviews failed checks, and maintains scripts when the monitored application changes. Zabbix's life cycle policy sets standard releases to a 12-month support period and LTS releases to five years, so plan a recurring upgrade window. Paid Zabbix technical support is optional and is sold in tiers from Silver to Global, with response times from one day to one hour, according to the Zabbix support page. Whether you need one depends on how quickly you must restore a failed monitoring check.

The one-time costs are the setup and scripting effort, which you should price as a fixed scope before work starts. This includes building uptime and API checks, writing and validating browser scenarios, configuring private locations or proxies, wiring alerts and status pages, and running the Datadog and self-hosted checks in parallel until results match. Ask any implementation partner for a written quote that lists each check group, the number of browser journeys, the environments covered, the alert routing, and the hours or fixed fee for each. Also ask who keeps the scripts current after handover and what is excluded. Request the quote in a form that separates one-time build from recurring operations, so you can compare it with your Datadog run counts over a full contract term.

The scoping work starts with an inventory of every synthetic test in the Datadog account: each Synthetic API test, each browser test, its frequency, the locations it runs from, its assertions, and the alert and notification rules attached to it. Teams often discover that a number of tests were created for a release or an incident and never retired, so the inventory also records owners and whether each check still protects a live service. Ask for an export of the test definitions and the monitor list from your own administrators rather than relying on memory, and confirm which tests run from managed Datadog locations versus private locations, because that decides where replacement probes must sit.

The output of scoping is a written fixed scope agreed before any work starts. It names the deliverables (for example, which uptime and API checks move to self-hosted Uptime Kuma, which browser scenarios are rebuilt on Zabbix, the status page and notification routes, and the cutover plan), the acceptance criteria for each, the environments involved and the timelines the parties have agreed. Most DeployOpen engagements are scoped this way, so the reader should expect a written statement of work and should check that browser scenarios, which need more design work than HTTP checks, are sized separately from simple endpoint checks. Ask for the scope to list what is excluded, including any test you intend to keep on Datadog during dual running.

Once the replacement is live, checks drift as applications change and as Zabbix and Uptime Kuma releases arrive. For that stage, DeployOpen offers an optional retainer covering upgrades, periodic review of the test inventory, and continuous checks against the self-hosted monitoring stack. Decide before signing whether your team will own routine test changes or whether a retainer should carry them, and confirm who patches the Zabbix server and proxies, since Zabbix support tiers from the vendor are a separate purchase from the implementation work. DeployOpen does not publish prices, so ask for a quote built from the agreed inventory and deliverables.