Alert rules & alert records

The alerting module periodically scans API call logs, identifies anomalies according to rules, and sends notifications through email and other channels. Rules are created per environment and linked to APIs; trigger records can be traced back to the specific API, release version and traceId.

Entry points

Feature	Entry
Alert rules	Alert notifications → Alert rules
Alert records	Alert notifications → Alert records

Both lists support filtering by keyword and environment, and are isolated by project.

Alert rules

List fields

Column	Description
Rule ID	Rule number
Rule name	A name that makes the rule easy to identify
Alert type	Timeout, HTTP status code, business status code, error rate, consecutive failures
Condition	Rule condition, such as > 500ms, ≠ 500
Notification method	Email, SMS, Webhook tags
Frequency	Maximum number of sends per hour
Status	Enabled / Disabled
Modified time	Last update time

Actions include edit, link API and delete. A rule that is already linked to APIs cannot be deleted; unlink it first.

Create an alert rule

The rule form is divided into four parts: basic information, condition configuration, statistics configuration and notification configuration.

Basic information

Field	Description
Rule name	Required
Environment	Cannot be changed after creation
Alert type	Determines the subsequent condition and statistics fields
Rule description	Optional; explains the purpose of the alert

Alert types and conditions

Type	Meaning	Condition fields	Default condition
timeout	A single request takes longer than the threshold	Threshold (milliseconds), comparison operator	>
http_status	HTTP status code match	Status code (multiple values can be comma-separated), comparison operator	≠
biz_code	Compares a specified field in the response body with an expected value	Field path, expected value, comparison operator	≠
error_rate	The error rate within the time window exceeds the threshold	Threshold (percentage), comparison operator	>
consecutive_fail	Counts consecutive failures backwards from the latest request	Threshold (count), comparison operator	≥

Comparison operators support >, <, =, ≠, ≥ and ≤. Business status code fields use a dot-separated path, for example data.code, extracted level by level from the JSON response body.

Statistics configuration

Field	Applicable types	Description
Time window (seconds)	Timeout, error rate, consecutive failures	Time range for scanning logs; defaults to 600 seconds
Minimum requests	Error rate, consecutive failures	Does not trigger when the number of requests in the window is insufficient, avoiding false positives from small samples

Notification configuration

Field	Description
Notification method	Email is currently available on this page; the backend also supports SMS and Webhook, but no configuration entry is exposed in the page yet
Alert email addresses	Separate multiple addresses with English commas; each address is validated individually
Alert frequency	Maximum number of sends per hour; once the limit is reached, no more notifications are sent during the current hour
Status	Enabled or disabled

SMS and Webhook

The backend supports Alibaba Cloud SMS, as well as WeCom, DingTalk, Feishu and custom Webhooks, and displays the corresponding notification methods in lists and records. The current edit page only exposes the email checkbox; to use SMS or Webhook, configure them through the API or a future page version.

Link APIs

After a rule is saved, click "Link API" to select APIs in the current environment. Rules without linked APIs do not generate any alerts.

Links are isolated by environment: a rule only scans API logs from the environment in which it was linked.

Execution logic

Alert scanning is driven by a scheduled task, by default once every 10 minutes, adjustable via apigo.warn.scan-cron; apigo.warn.enabled=false disables alert scanning. In multi-instance deployments, a Redis distributed lock ensures that only one instance runs at a time.

Log source

By default, logs are read from the call log table in the database; when spring.elasticsearch.enabled=true, they are read from Elasticsearch instead. Both paths use the same API, environment and time window conditions.

Evaluation by type

Type	Evaluation method
Timeout	Iterates through the logs in the window and finds records whose response latency meets the condition; triggers only once per API
HTTP status code	Matches a single status code or multiple comma-separated status codes; triggers only once per API
Business status code	Extracts the dot-separated path field from the response body and compares it with the expected value; triggers only once per API
Error rate	Groups by API and calculates failures ÷ total; triggers when the threshold is reached and the minimum request count is met
Consecutive failures	Counts from the latest request in reverse chronological order and stops at the first successful request

A request is considered failed when the request status in the call log is empty or not equal to success.

Deduplication and frequency control

Mechanism	Scope	Rule
Hourly frequency	Rule	Once the configured count is reached, no more notifications are sent during the current hour
Log deduplication	Single log + rule	The same log does not trigger another alert within 24 hours
Active state	Window-based rule + API	An API that has already triggered an alert does not alert again during the window; the state is cleared after the metric recovers

For window-based rules (error rate and consecutive failures), the active state TTL is the greater of the time window and 300 seconds, avoiding frequent duplicate notifications when the window is too short.

Notification delivery

• Each notification channel is sent independently; as long as one channel succeeds, the alert is recorded as successful;
• Emails are sent one recipient at a time; a failure for one recipient does not affect the others;
• SMS is sent through Alibaba Cloud SMS and requires an AccessKey, signature and template;
• Webhooks support the Markdown/text formats of WeCom, DingTalk and Feishu, as well as custom JSON;
• Every send writes an alert record that captures the delivery result for each channel.

Alert records

List fields

Column	Description
Record ID	Alert record number
Alert type	Type of the triggered rule
API name	API that triggered the alert
Environment	The environment
Condition	Rule condition and threshold
Trigger value	Actual trigger value, such as 820ms, 12.50%, 5 times
Notification method	Notification channels configured for this alert
Delivery status	Success / Failed
Alert time	Record creation time

Details

Click "Details" to view:

• Rule name, type, condition, trigger value and threshold;
• API name, path, environment and release version;
• traceId and request time;
• Delivery status and delivery details;
• Alert summary explaining the trigger reason.

Alert records are read-only; delete and resend operations are not provided.

FAQ

Symptom	What to check
Rule does not trigger	Whether the rule is enabled, whether APIs are linked, and whether the linked environment is correct
Alert delay	Scanning runs once every 10 minutes by default, so this delay is expected; adjust the cron if needed
Error rate never triggers	Whether the number of requests in the window reaches the minimum request count
Consecutive failure count is lower than expected	Counting proceeds backwards from the latest request until a successful request, which truncates the count
Duplicate alerts received	Check whether the link scopes of different rules overlap, and the hourly frequency setting
Delivery status failed	Check the email service configuration, recipient addresses, and SMS or Webhook configuration
Business status code cannot be extracted	Confirm that the response body is JSON and the field path matches the response structure

Limitations

• Alerts are based on historical log scanning, not real-time streaming detection, so triggers are delayed by the scan cycle;
• A single rule can link only APIs in the same environment;
• The page currently exposes only email notification configuration;
• Alert records are not cleaned up automatically; define an archiving strategy based on database capacity;
• Alert rules do not replace rate limiting and circuit breaking: the former detects anomalies, while the latter provides real-time protection.