Skip to main content

​
What it does

For every project and eligible metric, Cekura categorizes failing calls continuously as they come in:
  1. When a call fails a metric, its root cause is classified into that metric’s failure-mode set — reusing an existing mode when a single fix would resolve it, or opening a new mode when nothing fits. A call with more than one distinct root cause lands in multiple modes.
  2. Each failure mode carries a running count and its example calls; a periodic pass merges near-duplicate modes that share a single fix.
  3. The metric’s Insights card shows its failure modes sorted by frequency, defaulting to the last 24 hours — adjust the date range to widen or narrow the window.
These insights surface the dominant patterns behind a metric’s failures, so you can fix the agent instead of re-reading every flagged call.

​
Viewing and generating insights in the dashboard

Navigate to Observability → Insights in the sidebar. The page displays a card for each metric you’ve enabled insights for. Use the View dropdown at the top of the page to filter by view. When a view is selected, the page shows only metrics and insights for agents in that view. Use the agents dropdown next to the date-range picker to filter by specific agents. When agents are selected, failure-mode counts, example calls, and failure rates reflect only calls handled by those agents; failure modes with no matching calls are hidden. Clear the selection to include every agent. Each card shows one of the following:
  • The latest failure-mode audit with identified themes
  • A message indicating not enough failures were found in the analyzed window
  • A Generate button if no audit has run yet
Click Generate (or Regenerate for an existing audit) to run a new analysis on demand. The page polls automatically until the audit completes. Each failure theme includes a title, a brief description, and clickable call IDs that link directly to the corresponding call logs.

​
Enabling insights for a metric

Insights are opt-in per metric. A metric produces no failure modes until you turn it on and tell Cekura what a passing call looks like for it. On the Insights page, click Enable insights for a metric, pick the metric, then set its passing threshold — the condition a call must meet to count as a pass. Calls that don’t meet it are the failures Cekura investigates. The threshold uses the same condition shape as a rubric rule. It applies only to new evaluated calls after Insights is enabled: Cekura does not reprocess historical calls. Failed calls are triaged as they arrive, so the metric’s failure modes populate over time. To change the threshold later, reopen the metric’s card configuration; to stop analysing a metric, turn insights off.
Insights cost 10 credits per metric per day. The dialog shows this cost before you enable a metric.

​
Prioritizing metrics

Metric cards are grouped into Custom Metrics and Predefined Metrics sections. Drag the grip handle in a card’s top-right corner to reorder cards within their section, so the metrics your team watches most sit at the top. The order is saved for the whole project, so everyone viewing Insights sees the same arrangement. Reordering isn’t available to members with read-only Insights access.

​
Which metrics are eligible

Any metric you evaluate on call logs can drive insights — LLM Judge, code-based, and predefined metrics alike. Failure is decided by the metric’s own passing criteria rather than by its type, so metrics such as Latency, WPM, and Talk Ratio are no longer excluded. A metric needs both of the following:
  • Evaluated on call logs. A metric that doesn’t run in Observability can never produce a failure to investigate.
  • Insights enabled, with passing criteria set. Both come from the step above.
The project rubric no longer governs insights. Adding a metric to the rubric does not enable insights for it, and enabling insights does not make the metric count toward call success — the two are configured independently.