A manufacturer may run a separate Prometheus instance in each of a dozen factories. The group may also have several ClickHouse clusters across regions, while individual teams operate their own PostgreSQL, MySQL, and logging systems. Network isolation, data sovereignty, and cost make moving all of that data into one place impractical.
These companies rarely lack monitoring tools. Their real problem is that monitoring operations have fragmented along with the data.
The same infrastructure alert gets configured in every Prometheus instance. Checking one region means finding the right URL and credentials. Some rules are failing to execute; others are actively firing. Yet the on-call engineer has to move between multiple systems to reconstruct what is happening. As the number of data sources grows, this repetitive work becomes a permanent operational tax.
Flashduty Monitors addresses that problem with a simple architectural choice: keep data inside the customer's private environment, while managing alerting rules, runtime status, and investigation from one place.
Centralize the Control Plane, Not the Data
Sending telemetry from dozens of environments into a new SaaS datastore sounds straightforward. In practice, it creates another set of costs and risks: network egress, long-term retention, compliance reviews, data migration, and consistency between the new platform and existing pipelines.
Flashduty Monitors takes a lighter approach. Monit Edge runs inside the customer's environment, connects to local data sources, and executes queries there. Flashduty SaaS manages rules, organizes runtime status, and provides query and visualization workflows when needed. Raw telemetry does not need to be continuously copied into SaaS, and teams do not have to buy a second telemetry store just to gain centralized alerting.
This is not a cloud migration for the data plane. It is a cloud control plane for monitoring. That distinction matters in environments where a single, centralized monitoring deployment is unrealistic:
- Factories or campuses operate isolated data sources and networks.
- Regions are separated by data residency or cross-border compliance requirements.
- Business units have independent data platforms and operations teams.
- Mergers and years of infrastructure growth have left behind a mix of Prometheus, ClickHouse, PostgreSQL, and other systems.
- Edge sites are numerous but individually small, making centralized storage uneconomical.
One Alerting Rule, Many Data Sources
Once data sources become distributed, rule duplication is one of the easiest problems to underestimate.
Imagine a company with 20 factories, each running its own Prometheus instance. If every environment separately defines alerts for CPU, disk capacity, instance availability, and critical services, the same monitoring intent quickly becomes 20 copies. Changing a threshold, adding a label, or refining a recovery condition means repeating the change 20 times. Given enough time, those rules will drift.
In Flashduty Monitors, one alerting rule can apply to multiple data sources. The team maintains the monitoring intent once, and the rule is executed against every matching source. For factories, regions, or business units that share metric conventions, this reduces duplication and makes consistent governance possible.
Alert conditions also need more than one evaluation model. Flashduty Monitors supports threshold, data-present, and data-missing alerts. A metric crossing a threshold can trigger an alert. So can a query returning matching records, or an expected signal disappearing. Recovery can happen when the original condition clears or when a separate recovery query confirms that the business has actually returned to normal.
That last distinction is important. An alert and its recovery should describe the same business reality. A queue dropping below a threshold and an order pipeline producing successful transactions again are related signals, but they are not the same proof of recovery.
The Rule Tree Is an Operational Map
A flat list stops working when rule and data-source counts grow. During an incident, the questions are hierarchical: Which business group is alerting? Which region has execution failures? Which sites are healthy?
Flashduty Monitors organizes alerting rules as a tree. Teams can model their structure by group, region, factory, business unit, or another operating boundary. Each node surfaces active alerts and rule-execution failures, turning the rule hierarchy into a live map of system health.
An unreachable data source should not remain hidden until someone happens to open a rule detail page. A burst of alerts from one factory should not require an engineer to filter dozens of records before noticing the shared scope. Aggregating status at each tree node answers the first question in incident response: where is the problem concentrated?
Ad Hoc Queries Need One Entry Point Too
An alert tells the team that something is wrong; investigation still requires access to the underlying data. Traditionally, on-call engineers sign in to each factory or regional monitoring system, remember where every data source lives, and repeat similar queries. Comparing environments means switching between browser tabs and interfaces.
Flashduty Monitors now includes an ad hoc query workbench. Users select a data source and run a query from one page instead of signing in to every monitoring system inside the customer's network. Prometheus metrics, database queries, and additional data-source capabilities can gradually converge in the same investigation workflow.
Data ownership does not change. Queries still execute against data sources in the customer's environment; SaaS provides the common access point and result-analysis experience. For on-call engineers, the workflow changes from "find the right system first" to "select the source and investigate." For platform teams, it reduces the need to distribute backend credentials or expose management endpoints broadly.
Bringing Nightingale's Proven Ideas to a Cloud–Edge Architecture
At Flashcat, we have maintained the open-source Nightingale monitoring project for years. Our understanding of multi-source alerting, rule governance, and day-to-day investigation did not begin with a SaaS interface. These capabilities have already been exercised in Nightingale and in a wide range of enterprise environments.
Flashduty Monitors is bringing that experience into a cloud–edge architecture. It preserves the flexibility of distributed data sources and private execution without requiring each company to operate an entire monitoring control plane. AI-assisted query generation and dashboards are also in development. Over time, alerting, ad hoc queries, visualization, and AI-assisted investigation will share the same data-source management layer—without making a full telemetry migration the price of entry.
Lightweight—and Included
Flashduty Monitors does not require a new centralized TSDB, historical data migration, or additional fees based on telemetry storage volume. The service is available to teams with a Flashduty On-call account.
For organizations already running Prometheus, ClickHouse, PostgreSQL, and other data sources across factories, regions, or business environments, there is no need to replace the existing data plane. Start by connecting current sources and standardizing the most important alerting rules. Then extend the same control plane to ad hoc queries and, as they become available, dashboards and AI-assisted investigation.
Data sources can remain distributed. Data can remain inside the company's own networks. Alerting rules, operational status, and the investigation workflow do not need to remain fragmented.
Learn more and try Flashduty: https://flashduty.com/
