Browse documentation

Respond

Create useful alerts

Notify the right people about customer-impacting failures without creating noise.

An alert should describe a condition someone can act on. Start with customer symptoms and critical journeys, then add service-level alerts only where they support that response.

Add a destination

Open Settings → Notifications and create a notification channel for direct rule delivery. Send a test notification before attaching it to a production rule. Add personal contact methods only when the rule routes through an escalation policy or on-call schedule.

Available destinations depend on the connections enabled for your organization. Webhooks can cover destinations without a dedicated integration.

Create a rule

Open Alerts and create a rule. Define:

  • the project and environment;
  • the signal or customer being watched;
  • the condition type, its specific settings, and the evaluation window;
  • how long the condition must remain true and then remain clear; and
  • the notification destination.

Use a sustained firing window for noisy metrics and a recovery window when one healthy evaluation should not close an incident. A breach during recovery restarts the healthy window. Use immediate notification and recovery only for conditions where one event is decisive, such as a critical customer error.

For a metric rule, select metrics, add a metric_name filter, and use the same aggregation and window you already validated in Explore → Metrics or a dashboard. A threshold is the clearest choice for a hard service limit. An anomaly condition can preview an expected band when metric_name is present, but it remains an approximate signal rather than proof of a problem.

Query fields

Rule filters are exact, case-sensitive string matches. Choose a field from the dashboard picker or use one of the API fields below. Anectico validates and normalizes the query before saving the rule, so a typo or a field from the wrong signal returns a validation error instead of creating a rule that fails later. service is the portable field for every signal and maps to the stored service_name column. The canonical service_name spelling is accepted too. Logs also accept level for severity; traces accept operation for operation_name and status for status_code.

Signal Exact-match filter fields
Errors service, service_name, environment, error_id, error_group_id, group_id, fingerprint, error_type, type, message, release, dist, user_id, user_email, user_ip_address, trace_id, span_id, session_id, distinct_id, request_method, request_url, platform, sdk_name, sdk_version, project_id
Logs service, service_name, level, severity, severity_text, message, environment, trace_id, span_id, logger_name, host, pod_name, source_file, distinct_id, session_id, project_id
Metrics service, service_name, metric_name, name, metric_type, type, environment, project_id, unit, description, aggregation_temporality
Traces service, service_name, operation, operation_name, status, status_code, status_message, span_kind, environment, trace_id, span_id, parent_span_id, distinct_id, session_id, project_id, gen_ai_system, gen_ai_model, gen_ai_operation, gen_ai_cost_source, gen_ai_conversation_id, gen_ai_agent_name, gen_ai_agent_id, gen_ai_tool_name, gen_ai_response_id, gen_ai_finish_reason

count can omit its field. Numeric reducers (sum, avg, min, max, p50, p95, and p99) accept value for metrics, duration_ns and the numeric gen_ai_* token/cost fields for traces, or source_line for logs. Errors support count only. Grouping is also signal-specific; the rule editor shows the supported dimensions. Filter objects, arrays, nulls, comparison operators, arbitrary free-form expressions, and unknown identifiers are rejected before the rule is persisted.

For a heartbeat, scheduled job, or other expected signal, choose an absence condition. It checks whether the filtered query matched any source rows during query.time_range, which is the sole lookback. Raw, grouped, and aggregate queries are supported; a real aggregate value of zero still counts as present data. The condition does not use an operator, threshold, result field, or its own time_window.

Test before enabling

Use the rule test action and confirm the message contains enough context to begin an investigation: the condition, severity, project, environment, time, and a link back to Anectico.

Respond to an alert

  1. Acknowledge when someone takes ownership.
  2. Open the linked customer, Issue, trace, or service evidence.
  3. Create an incident when coordination or a durable case file is needed.
  4. Resolve after the condition has cleared and follow-up is recorded.

Use a silence for planned maintenance or a known temporary condition. Give every silence an owner and expiration time. Matching alerts show silenced with that provenance; acknowledging one keeps the responder-owned state until the acknowledgment is cleared. If maintenance ends while the condition still breaches, the alert returns to firing and notifies once on its next evaluation.

Tune based on outcomes

Review alerts that fired without action and alerts that should have fired but did not. Change the condition, window, or routing rather than training the team to ignore noise.