Dependencies and analytics

Dependency model

A dependency edge means a downstream monitor relies on an upstream monitor. In storage and API operations, monitor_id is downstream and depends_on_id is upstream.

Checkout API (downstream) ──depends on──► PostgreSQL (upstream)

Graph edge response:
{ "from": "<checkout-id>", "to": "<postgres-id>" }

Dependency validation

• Both monitors must be live resources in the authenticated tenant.
• A monitor cannot depend on itself.
• Any direct or transitive cycle is rejected with HTTP 409 and the dependency_cycle error code.
• Adding an existing edge is deduplicated instead of creating parallel edges.
• Removing a nonexistent edge is idempotent.

A depends on B
B depends on C
C depends on A   ← rejected

The dependency graph response contains only monitors that participate in at least one edge. Node records include ID, name, type, current state, and last state change; an unconnected monitor is absent rather than returned as an isolated node.

Root-cause annotation

When an availability alert opens or is reevaluated, Probara traverses upstream dependencies and selects the deepest currently down candidate. When candidates are at the same depth, the one that became down first wins.

Public API (down)
└── Checkout service (down)
    └── Primary database (down)

Annotated root cause: Primary database

The annotation is updated as states change and cleared when no down upstream candidate remains. It is evidence for prioritization, not proof of causality.

AI-assisted dependency suggestions

With workspace local AI enabled, at most 50 candidates are prioritized by co-firing alerts, shared service tags/groups, then naming signals. The alert lookback is 30 days, with co-firing measured in fixed 10-minute buckets. Proposals require repeated directional timing, service corroboration and a calibrated score threshold; conflicting directions and known common upstreams abstain. Correlation alone does not prove a dependency.

Suggestions include measured counts, median timing, corroborating signals, calibrated score, model identity, evidence references and abstained-pair context. Duplicate, existing, self and cycle-producing proposals are rejected, including paths through monitors outside the candidate set. The endpoint is compute-only: it does not write an edge until an operator explicitly accepts and creates it. The Suggest with AI button is disabled while local AI is off for the workspace or installation, or the local service is unavailable (see Settings → AI); the page rechecks every 30 seconds and when you return to the tab, and re-enables the button once local AI is ready. The endpoint itself answers 503 while local AI is off, or busy or restarting (with Retry-After).

Each operator decision on a suggestion is recorded as a training label for the local model. Accept and add dependency saves the edge first, then records a confirmed label; if the edge cannot be saved, nothing is recorded. Dismiss records a rejection as not a dependency, and the row menu offers the reasons wrong direction, shared upstream explains both, and not enough evidence. The server recomputes the pair's evidence when the label is saved, so it is what the advisor would send at that moment rather than anything from the browser; a pair that is no longer a candidate cannot be labelled. Viewers cannot accept or dismiss. See AI label endpoints.

Dashboard overview

The overview combines monitor and alert totals, state distribution, historical trend, 24-hour activity, platform operational health, problem monitors, recent failures, recent alerts, and available tags for the authenticated tenant.

Problem-monitor, recent-failure, recent-alert, and summary endpoints are also available independently so clients can refresh a focused panel without reloading the complete overview.

Service summary and groups

Tenant settings define a curated ordered list of dashboard group tags. The summary uses those tags to build service rows and adds an ungrouped bucket for monitors that do not match. Each row includes member state, uptime/attention signals, and a worst-state summary.

The group-sparkline endpoint returns the historical series for one dashboard group, allowing a client to defer the more expensive time-series request until the group is visible or expanded.

Per-monitor analytics

Allowed ranges are 1h, 6h, 24h, 7d, 30d, 90d, and 365d, with 24h as the default. Not every monitor type emits every metric, so consumers should handle absent latency or TLS values rather than displaying zero.

Rollups and data coverage

The scheduler builds hourly and daily rollups behind a high-water cursor. Long-range analytics combine completed rollups with a raw-result tail so recent checks appear before the next aggregation interval completes.

Raw source

Fine-grained recent check results, suitable for short ranges and detailed failure inspection.

Rollup source

Aggregated hourly or daily buckets used for efficient longer-range queries.

Partial coverage

The requested range begins before the oldest retained usable result or rollup.

Results marked with result_source=platform are excluded from standard monitor analytics. This applies to expired-job results; generated stale-agent/push state records are written with result_source=monitor and are counted like ordinary results.

Retention

Tenant telemetry retention is 0 for unlimited retention or a value from 30 through 3,650 days, and governs mesh history. Raw check results are kept 30 days for every tenant; longer ranges are answered from hourly and daily rollups, kept 400 days. See the scheduler's retention tasks.

Diagnostic workflow

1. Start with the problem-monitor and recent-alert views to determine current impact.
2. Open the dependency graph and validate whether the annotated upstream monitor is genuinely causal.
3. Compare raw recent failures across locations; a degraded regional result can precede a quorum-confirmed outage.
4. Inspect per-monitor latency, downtime periods, and coverage metadata.
5. Check maintenance and deployment history before concluding that correlated alerts share a dependency.
6. Attach relevant alerts and monitors to an incident, preserving hypotheses as internal notes.