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 an effective tenant AI configuration, the suggestion endpoint analyzes recent alert co-occurrence and asks the configured model for plausible upstream relationships. The current analysis window is 30 days, co-firing events are paired within 10 minutes, and a candidate pair needs at least two observations.

Suggestions include a reason, confidence, model information, and analyzed-pair context. The endpoint is compute-only: it does not write an edge until an operator explicitly accepts and creates it.

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. Cleanup covers check results, mesh history, and rollup data according to 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.