Rules, Reports, and Notifications
Product behavior for the signal and summary layers in Logga.
Raw telemetry is useful, but the product becomes operationally valuable when that telemetry turns into action. In Logga, that action layer is built from rules, notifications, and reports.
Rules
Rules describe conditions that should produce an alert-worthy outcome.
Current implementation characteristics:
- rules belong to a workspace and environment
- rules may optionally target a single channel
- rules are persisted as JSON conditions
- rules can be toggled active or inactive
Examples of rule intent:
- alert on any error-level event
- alert when payment volume exceeds a threshold in a time window
- alert when a channel goes quiet for too long
Notifications
Notifications are the persisted result of rule evaluation.
A notification can point back to:
- the triggering rule
- the related event, if one exists
- the related session, if one exists
- the related channel, if one exists
This makes notifications more than ephemeral push messages. They also become historical records the clients can browse.
Reports
Reports are scheduled rollups over event history.
The current reporting model supports:
dailyorweeklyschedules- metrics:
count,sum,average - optional aggregate field for numeric payloads
- filter objects
- optional grouping by actor
- one or more channel targets
The iOS app already exposes report management and recent results. The backend stores both the configuration and recent execution outputs.
Mental Model
Use this framing when deciding where a feature belongs:
| Need | Best fit |
|---|---|
| Immediate signal about a live problem | Rule + notification |
| Ongoing record of significant incidents | Notification history |
| Regular summary or KPI rollup | Report |
| Raw searchable source data | Event or session feeds |
Example Rule Shapes
Error event rule
{
"type": "on_event",
"level": "error"
}Threshold rule
{
"type": "threshold",
"operator": "gt",
"value": 5,
"windowMinutes": 10
}Example Report Ideas
Daily revenue summary
- schedule:
daily - metric:
sum - aggregate field:
amount - filter:
eventType = payment_succeeded
Weekly auth failure report
- schedule:
weekly - metric:
count - filter:
eventType = login_failed - group by: actor
UX Implications
When designing client behavior, rules and reports should feel meaningfully different:
- rules are reactive and urgent
- reports are reflective and periodic
That difference should show up in naming, placement, and copy.