Signals
A signal is an observable condition on an entity in your system, such as elevated latency or a rising error rate. Signals are the primary inputs to Causely's causal reasoning engine. When a Signal is active, the engine uses it, together with your system topology and other active Signals, to infer a Diagnosis automatically.
A signal is a named condition on an entity (service, workload, container, database, node, and others) that is either active or inactive. It becomes active when a specific metric crosses its threshold and holds for a sustained period. Each signal has three parts: the metric or attribute being monitored, the threshold at which it triggers, and a description of what an active state indicates.
Signals can be:
- Local: Observable in the entity where the Diagnosis occurs
- Propagated: Observable in related entities due to Diagnosis propagation
How signals activate
Signals activate automatically with no configuration required, and every part of that behavior can be tuned when defaults need adjusting.
Configurable thresholds. Every signal is driven by an underlying metric and a threshold. Thresholds are configurable and have one active source at a time: a system default, a value Causely learns from your traffic, or a manual override. See Threshold configuration.
Controllable activation delay. A signal does not activate on the first breach. The condition must hold for a sustained period first, which suppresses transient spikes. The bursty activation delay defaults to 5 minutes and is configurable per service. See Signal delay.
Activation from existing alerts. Signals can also be activated by alerts you already run. Causely maps alerts from Prometheus Alertmanager, Datadog, Dynatrace, and Grafana onto the matching signal, so existing alerts feed the causal model without changing how you alert today. See Alert ingestion.
From Signals to Diagnosis
Signals are used by Causely's causal reasoning engine to infer a Diagnosis. When multiple Signals are present, Causely analyzes their relationships and patterns to identify the most likely explanation. The output is a Diagnosis with its blast radius and supporting evidence, structured for an agent, an automation workflow, or an engineer to act on directly.
Signals describe what you observe (for example, high latency, errors, timeouts); a Diagnosis describes why it happens (for example, congestion, lock contention, queue saturation). They can sound similar, but they're different: latency is the effect, congestion is the cause, and fixing the cause is what prevents the Signal from returning.