v1.0.132
Expanding the Causal Model
Causely now lets engineers add custom cause definitions to the causality graph, extending the model to cover failure modes outside Causely's built-in diagnoses. Previously, alerts not tied to the built-in model were discarded: the failure modes they represented could not participate in causal reasoning and never surfaced as root causes, regardless of how often they occurred. A custom cause definition is not a relabeled alert: it becomes a node in the causality graph, enters the codebook, and is evaluated alongside built-in causes as symptoms propagate through the topology. Definitions can be created from the Integrations → Alerts view and managed under Settings → User Defined Causes; alerts without entity mapping will display a clear prompt indicating what configuration is required.
Expanded MCP Tools
Causely MCP now includes five new tools for exploring blast radius and the causal model in depth: what could cause a given signal, what signals a diagnosis would produce, what alternative diagnoses exist for an entity, and which entities have the most dependencies. Before this release, agents could retrieve active diagnoses but had no way to explore why a root cause was selected, what else could explain a symptom, or how far a failure would propagate. These tools close that gap, enabling agents to explain their conclusions and surface causal context that previously required manual investigation. The new tools are get_potential_diagnoses, get_potential_observable_signals, get_signal_potential_diagnoses, get_diagnosis_observable_signals, and rank_entities.
BYOC and Installation Customization
Causely now supports SSO and role-based access control through any OpenID-compatible identity provider, and allows teams to configure which AI model generates root cause summaries and remediation suggestions. For Bring Your Own Cloud (BYOC) deployments, this removes a common blocker: enterprise environments that require integration with an existing identity provider or need to control which AI model is used due to compliance or cost policies can now configure both directly.
This release also expands infrastructure flexibility: the mediator now supports a managed Prometheus backend in place of the built-in VictoriaMetrics, and can be deployed outside Kubernetes in environments such as ECS clusters.
Minor Improvements
- Notification filtering by entity: Root causes affecting a specific service can now be routed to a dedicated Slack channel, enabling more precise alert ownership and on-call routing.
- Symptom history: Historical symptoms that have since resolved are now visible in the UI and queryable via agent, for example asking whether a specific endpoint had elevated error rates in the last 24 hours.
- Simplified notification setup: Generic webhook notifications no longer require configuring the Causely Bot, reducing setup steps for new integrations.
- Kubernetes alert mapping: Kubernetes alerts are now mapped more accurately to Causely symptoms, making it easier to understand the root cause of infrastructure-level alerts.
- Beyla updated to 3.20.0: Improves parsing of GenAI-related telemetry.
- Refined alert state categories: Clearer distinction between alerts unmapped due to missing entity labels and alerts for entities not yet present in the discovered topology. Learn more about alert mapping.
- Slack thread notifications: Slack notifications now support a shorter initial message with full detail in the associated thread, reducing channel noise without losing context. Learn more
- Root cause log annotations: Log entries associated with a root cause are now more precisely selected and annotated, improving the relevance of information used in suggested remediations.