To experience Monitors features, there are three core steps:
Install monitedge
Deploy the alert engine to your private network
Create Data Source
Configure the data sources to monitor
Create Alert Rules
Define alert conditions and notification methods
Install monitedge
monitedge needs to be deployed in your private network. It is responsible for syncing alert rules from SaaS, periodically querying data sources, performing threshold evaluation, generating alert events, and pushing them to the SaaS.
Menu Entry: Alert Engine → Engine Installation/Upgrade
Supports Linux, Docker, and Kubernetes installation methods.
Engine Cluster Name is very important: monitedge instances with the same name form a cluster, sharing the workload of processing alert rules to avoid single points of failure.
- Single cluster: Keep the default
default
- Multiple clusters (e.g., one in US-East datacenter, one in South China datacenter): Specify different names for each cluster
Alert Engine Status
After monitedge is installed, it automatically connects to the SaaS and periodically syncs alert rules. You can view current status information on the Alert Engine Status page.
Engine instances without heartbeat for a long time will display a delete button, which you can click to remove and avoid engine disconnection alerts.
Engine Disconnection Alert
monitedge downtime has significant impact, so engine disconnection alerts are provided.
For an engine cluster composed of multiple instances, as long as at least one instance in the cluster is alive, the engine disconnection alert will not trigger.
Create Data Source
Menu Entry: Data Sources → New
| Config Item | Description |
|---|
| Associated Alert Engine | Specify which alert engine cluster performs data queries and alert evaluation for this data source; typically select a cluster in the same datacenter |
| Data Source Connection URL | The address for monitedge to connect to; must be an internal address accessible by monitedge |
Create Alert Rules
Menu Entry: Alert Rules
There may be many alert rules. Monitors provides a tree-structured grouping for categorized management. Each alert rule must belong to a group. You can create groups first, then create alert rules under the groups.
Basic Configuration
| Config Item | Description |
|---|
| Rule Name | Name of the alert rule; does not support variable references (fixed names facilitate filtering and grouping operations). It must be unique within its group; imports, edits, and moves fail if the target group already contains that name |
| Additional Labels | Similar to labels in Prometheus; attached to all alert events for filtering, routing, and inhibition |
Data Source Selection
Monitors supports a single rule applying to multiple data sources with two binding methods:
- Wildcard by name: Match data sources by name using wildcards.
* matches all data sources; db-* matches all data sources starting with db-. Stores name strings, so renaming a data source affects matching.
- Exact match by ID: Select specific data sources from a dropdown by ID. Unaffected by data source renames.
Both methods can be used together, and at least one must be specified. The rule applies to all data sources matched by either method.
If you need stable rule bindings that are unaffected by data source renames, prefer exact match. See Data Source Management for details. Query Detection Method
Configure how to query data sources and how to evaluate alert conditions. Please read the usage instructions on the right side of Query Detection Method on the page.
| Config Item | Description |
|---|
| Query Offset | Sets the query time offset (in seconds) to handle data source ingestion lag. For example, setting it to 60 shifts the query window back by 60 seconds, ensuring data has been fully written before querying |
Detection Frequency and Effective Time
| Config Item | Description |
|---|
| Detection Frequency | Usually periodic detection; also supports cron expressions (down to seconds) |
| Rule Timezone | The timezone in which the rule executes. It controls how cron schedules and Effective Time windows are interpreted. Defaults to Asia/Shanghai. Must be a valid IANA timezone name such as Asia/Shanghai, UTC, Europe/London, or America/New_York |
| Effective Time | Time period when the alert rule is effective; alerts will not trigger outside this period. Time windows are evaluated in the Rule Timezone above |
Timezone rules:
- Rule Timezone only accepts IANA timezone names. Shortcuts and offsets such as
Local, UTC+8, CST, or GMT+8 are rejected.
cron expressions must not start with CRON_TZ= or TZ=. If you are migrating from an open-source cron system that embeds the timezone in the cron string (for example, CRON_TZ=Asia/Shanghai 0 0 * * *), remove the prefix and set the timezone in Rule Timezone instead.
Event Configuration
| Config Item | Description |
|---|
| Custom Fields | Similar to annotations in Prometheus; can attach dashboard URLs, SOP URLs, etc. |
| Related Query | Not used for threshold evaluation, but can be included in notes as variable references (e.g., attach log samples) |
| Notes Description | Unstructured text field; supports variable references to help responders quickly locate issues |
| Channel | Specify a channel in Flashduty On-call; if not specified, delivery follows integration routing rules |
| Repeat Notification | Continues notifying when alert is not recovered; configurable interval and maximum count (default 10000) |
The maximum notification count does not represent the number of message reminders end users receive. Because alert events generated by Monitors are delivered to On-call, they may be grouped and noise-reduced; the final send count depends on On-call configuration.
View Results
After configuration is complete, if alert conditions trigger, the status before the alert rule will change to Triggered.
The search box in the alert rules list supports filtering by rule name, rule ID, or labels for quick navigation. You can also use the URL parameter ?rule_id=<ID> to jump directly to a specific rule.
Triggered to see the alert events generated by this rule (also viewable in On-call):
Click the alert event title to view details, which are divided into three tabs: Alert Overview, Timeline, and Related Events.
Batch operations
The alert rules list supports multi-select for batch operations, improving rule management efficiency.
Batch enable/disable/delete
After selecting multiple rules in the list, you can batch enable, batch disable, or batch delete them in one click.
Batch edit fields
After selecting multiple rules, click Batch Update to uniformly modify the following 10 fields:
| Batch-editable Field | Description |
|---|
| Additional Labels | Uniformly set labels |
| Data Sources | Uniformly switch data sources |
| Detection Frequency | Uniformly adjust the detection period |
| Rule Timezone | Uniformly switch the IANA timezone of the alert rule |
| Effective Time | Uniformly configure effective time periods |
| Query Delay | Uniformly set query delay time |
| Custom Fields | Uniformly configure annotations |
| Channel | Uniformly specify the channel for alert delivery |
| Repeat Notification Config | Uniformly set repeat notification interval and count |
| Debug Log | Uniformly enable or disable debug logging |
Batch move
After selecting multiple rules, you can batch move them to another folder.
Import alert rules
Monitors supports three import modes. You can choose the most suitable method based on the source.
Menu Entry: Alert Rules → Import
Import from rule repository
Select the Rule Repository mode to import existing rule templates from the rule repository. You need to specify the channel for alert event delivery when importing.
Import from JSON
Select the Flashduty Rules JSON mode and paste a JSON array of alert rules. This format is consistent with the JSON produced by the export feature, making it suitable for migrating alert rules across tenants or environments. You need to specify a channel when importing.
The JSON content must be in array format (starting with [), where each element is a complete alert rule definition.
Import from Prometheus YAML
Select the Prometheus Rules YAML mode and paste standard Prometheus alert rules YAML content.
Requires standard format with groups as the root node. YAML indentation must be correct, otherwise import will fail. Each rule must contain alert and expr fields.
Import results
If some rules fail to import, the system displays an import results table showing the import status and error message for each rule. When all rules succeed, a success message is displayed directly.
Export alert rules
Select the rules to export in the list and click the Export button. The system displays the full configuration of the selected rules in JSON format. You can:
- Download: Save the JSON as a
monit.json file
- Copy: Copy the JSON content to the clipboard
The exported JSON can be used for backup or imported into other environments via the JSON import mode.
Rule change history
Every alert rule has a complete change audit trail. You can view the Change History in the rule details to understand the historical modifications.
View change history
The change history list shows the following information for each operation:
| Column | Description |
|---|
| Operation Time | When the change occurred |
| Operation Type | Such as create, update, etc. |
| Operator | The user who performed the change |
Version comparison
Select two records in the change history list and click the Compare button. The system displays the differences between the two versions in JSON diff format, helping you quickly understand which configuration items were modified. 
