Analytics ยท scheduling and alerting

analytics-scheduled-report

A recurring report is only useful when reruns agree and every alert says exactly which measured value crossed which rule.

Public · synthetic demo
The problem

A dashboard alert without its rule is only a prompt to start over.

Scheduled analytics can quietly double-count reruns, lose period context, or label a spike without showing the threshold. This pipeline makes the report a pure function of the event log and its window.

Input

A six-week synthetic event and transaction log.

Events ingested: 23246
Date range: 2024-01-01 to 2024-02-11
Distinct days: 42
Daily window: 2024-01-15
Weekly window: 2024-01-15 to 2024-01-21
The money shot

The spike stays attached to its measured evidence.

Purchase events, daily window
949
Daily count change
471.69%
Daily alerts
2
Total alerts
3

The threshold rule fired at 949 against 700. The independent trailing-window rule measured mean 273.71, standard deviation 66.14, and z-score 10.21.

How it's verified

Daily and weekly windows are reported separately.

WindowPurchase countAlerts
2024-01-159492
2024-01-15 to 2024-01-2125581

The same input and window reproduce the same file, so a rerun does not create a second interpretation of the period.

Honest limitations

An alert is evidence of a threshold crossing, not a diagnosis.

  • The alert rules do not identify why the spike occurred.
  • Weekly aggregation can dilute a daily failure.
  • Thresholds are tuned to this synthetic fixture, not a real SLA.
  • The pipeline has no persistent run lock, event deduplication, timezone conversion, or late-arrival correction.
Measured values first; causes remain a human investigation. jigonyoo.com · Back to hub