atrixANALYTICS

Findings

Automatic anomaly detection with root cause, delivered to Slack, email or a webhook.

Status

Available Findings appear in the console's Findings section; destinations and rules are set under Settings → Alerts (or through the API below). Findings is a commercial feature of the hosted plans (source in ee/).

What is monitored

With no setup, Findings watches:

  • every metric in your catalog that is certified or marked for monitoring, when it is a funnel (monitored as first-to-last-step conversion) or a single-series total trend;
  • your busiest events over the last 7 days: up to 15 by default, each with at least 350 events a week.

Rules can add event-volume or two-event conversion monitors, and tune thresholds, cadence, minimum severity, destinations and the daily cap.

How detection works

CadenceHourly (the last hour, and the trailing 24 hours) and daily at 00:00 UTC (the trailing 7 days). Each hour is evaluated about 5 minutes after it closes.
BaselineThe same hours of the week, 1 to 8 weeks earlier; at least 4 usable weeks. A project's first week is never used.
GrowthFor counts, a robust weekly trend (Theil–Sen) is removed, so steady growth is not flagged.
SpreadA robust spread of the baseline (median absolute deviation) combined with sampling noise.
Firing ruleThe z-score, the absolute change, the relative change and the sample size must all clear their thresholds.
DirectionMetrics marked "higher is better" only raise drops, and the reverse.

Default thresholds:

ConversionCount
z-score3.54.0
Relative change10%25%
Absolute change2 points30 events
Minimum sample150100

One-hour windows and per-platform slices need a higher z-score. Hours with incomplete data (ingest lagging more than 15 minutes) are skipped and retried.

Root cause

Each finding is broken down by platform, country and feature-flag variant or experiment arm, then drilled into app version, OS and version, browser, device type, SDK and release. A segment is named as the cause only when it moved the same way, is itself significant, and explains a meaningful share of the change. For conversions, the change is split into a rate effect and a mix effect.

Findings also checks error events ($exception, $network_error, $request_failed) in that segment against the baseline, and attaches sample session replays.

Noise control

  • A release, flag change or experiment annotated in the last hour holds a finding back while things settle; an incident in the last 24 hours does too, and a marketing push explains a rise.
  • An open finding for the same monitor and segment is updated, not sent again.
  • At most 10 deliveries per project per day by default; findings over the cap or below the minimum severity (medium by default) are stored but not sent.
  • Feedback tunes each monitor: "not useful" raises its bar, "useful" lowers it. Mute a segment or a monitor for 1 to 365 days.

The write-up

The narrative follows the same grounding rules as Ask: every number is bound to evidence and checked. Where the region's model policy does not allow a model, a fixed template writes it instead. Each finding comes with a chart.

Delivery

DestinationNotes
SlackAn incoming-webhook URL (https://hooks.slack.com/…), with the chart
EmailSent through Atrix Mail, with the chart attached
Webhookhttps:// only. Body { type: "finding.created", id, finding }, signed with X-Atrix-Signature: t=<unix>,v1=<HMAC-SHA256 of "t.body">

WhatsApp delivery is Planned. Deliveries are retried up to five times within a day. Detection and delivery both run in your region.

API

Control plane (scopes alerts:read / alerts:write):

  • GET, POST /app/projects/{project_id}/findings/destinations, PATCH, DELETE …/destinations/{id}
  • GET, POST /app/projects/{project_id}/findings/rules, PATCH, DELETE …/rules/{id}

Region API (same scopes):

  • GET /findings (filter by status, paginate with limit and before) and GET /findings/{id}
  • POST /findings/{id}/feedback, POST /findings/{id}/mute, POST /findings/{id}/status (open, acknowledged, dismissed, resolved)

On this page