Skip to main content

v1.0.143

Business KPI detection​

Causely now detects drops in business KPIs and explains them, starting with concurrent users on a Business Application. Before, Causely could tell you a service was failing but not that users were being locked out of the application. Now a Concurrent Users Drop Signal fires when a Business Application's concurrent users fall below their lower threshold, and Causely traces the drop to a diagnosis on one of its member services. This connects technical problems to business impact.

You do not need to set the threshold or rely on an external alert. Causely learns a lower threshold from each application's own history, using the last day of data and building on stored daily history as it accumulates. If you already know the right threshold, you can map your own and Causely uses it instead.

Several existing diagnoses now explain user loss, including throttling, rate limiting, NGINX worker connection exhaustion, unavailable HAProxy backends, and load balancer misconfiguration. A new Client Connection Disruption diagnosis covers the case where existing client connections are dropped, for example by a load balancer or proxy change, and users then flood back in to reconnect. Causely recognizes that pattern from a new Request Burst Signal on HTTP paths and RPC methods, which fires when an endpoint's request rate climbs well above its recent average.

To get started, review the your services grouped into a Business Application and map its concurrent users metric through Prometheus.

Learn more

Snapshot tools in MCP​

Agents can now create, list, compare, and delete environment snapshots through the Causely MCP server, using create_snapshot, get_snapshots, compare_snapshots, and delete_snapshot. Before, snapshots were only available in the Causely portal. A snapshot captures topology, active diagnoses, and resource and service metrics over a window of up to two hours. Comparing a baseline snapshot with a later one returns an ACCEPTED or REJECTED assessment, along with added and removed entities, new and cleared diagnoses, and before and after CPU, memory, request rate, error rate, and duration. This lets a CI/CD pipeline or an agent decide whether a change caused a regression. Creating and deleting snapshots requires the Developer or Admin role.

Learn more

Topology discovery from Datadog and Observe​

Causely can now build topology from Datadog and Observe without installing Causely in your monitored clusters. For Datadog, Causely discovers Kubernetes entities, hosts, and APM services with their HTTP routes and RPC methods through the Datadog API. For Observe, Causely discovers Kubernetes entities and APM topology through the Observe API. In both cases, clusters already monitored by a Causely agent keep the agent's view. Teams that send their telemetry to these platforms get Causely's causal analysis from the data they already collect.

Learn more about Datadog · Learn more about Observe

Export Issues and Diagnoses to Observe​

Causely now sends Issues and Diagnose to Observe, so Observe's AI SRE can answer reliability questions from causes Causely has already identified. Before, the AI SRE had to work out the cause of a problem from raw telemetry on its own. Now it can start from the diagnosis behind each Issue, which makes its answers more consistent and helps users resolve problems faster. Observe is the first destination for Causely's new export framework and this capability is currently only supported for Causely BYOC deployments.

Learn more

Minor Improvements​

  • Onboarding: Invited users now follow a single onboarding flow: install, connect, verify data, and ask a first question through MCP.
  • Name resolution in MCP: name_lookup now matches partial cluster and namespace names, so "robot" finds robot-shop. A new service_types filter tells apart services that share a name in the same cluster and namespace, such as a Deployment and a CronJob.
  • MCP tool guidance: Tool descriptions and prompts now tell agents to scope service lookups by cluster and namespace. This stops agents from resolving to the wrong service when names repeat. Agents are also prompted to report feedback with submit_feedback after reviewing an Issue or diagnosis.
  • Faster throttling detection: Request throttling on an HTTP path now activates after 5 minutes instead of 10, so short throttling incidents at the edge are caught while they are still happening.
  • Entity sorting in the API: The GraphQL entities connection can now sort entities by number of dependents or dependencies.
  • Backstage alert mapping: Alerts that carry only a Backstage component label are now mapped to the related Kubernetes service on a best-effort basis.
  • GCP Hyperdisk limits: Disk limits now cover N4A and N4D VM types.
  • Scheduling diagnosis on unhealthy nodes: Taints that Kubernetes or a cloud provider sets on unhealthy nodes, such as not-ready or unreachable, no longer produce a false "missing toleration" diagnosis on the workload.
  • Initial sync for discovered accounts: Accounts discovered from Kubernetes secrets are now included in the mediator's startup sync, and failed initialization is retried. Before, these accounts could wait a full sync interval for their first data.