Concepts

Onelo Monitor uses a small, opinionated vocabulary. Learn it once and the dashboard, SDKs, and API will make sense.

Feature

A feature is a named code path you instrument. It is identified by featureName — a free-form string up to 200 characters. Examples: checkout.charge, voice.turn, pdf.export.

A feature is auto-created in monitor_features (with type sdk_event) on the first event the backend receives. You can also manually create a feature of type http_ping directly from the dashboard.

Run

A run is one execution of a feature. Every run always carries featureName, ok (success or failure), and createdAt. Most runs additionally include durationMs, source, platform, sessionId, userId, and meta. The error field is only present when ok=false. Runs are stored in monitor_events.

Source

Source tells you how a run was emitted. It is a closed list:

— feature_call — first lookup of a feature flag (auto-emitted by OneloFeatures).
— feature_call_summary — an SDK-side aggregate of repeated flag lookups, carrying the call count in meta.calls.
— track — wrapped via track(featureName, fn).
— event — manual event(featureName, ...) call.
— global_error — uncaught exception or unhandled promise rejection.

Anything outside this list is coerced to event on ingest.

Session

A session is a client-generated identifier that groups runs. Its lifecycle equals the lifetime of the id. Behaviour differs per platform:

— Swift & Flutter: persistent install-bound id (Keychain / secure storage) — survives launches, resets on reinstall.
— Web, Electron, React Native, Android: per-process UUID — a new id every launch (Web: every page reload).
— Python, Node.js, PHP (backend SDKs): per-process UUID — one per worker/pod, so a server session is not a person (Python sessions are excluded from the user count).

Sessions back the sessions24h metric and the run-drawer grouping. The incident affected_users is the count of app sessions active in the alert window — an approximation of reach, not a distinct count of users who hit the error.

Incident

An incident is auto-opened when a feature’s error rate trips its alert rule (default: 10% over 15 minutes). Incidents are auto-numbered INC-0001 per workspace (unique across all your apps) and carry peakErrorRate, lastError, affectedUsers, and a priority (default high).

Incidents auto-resolve: when the error rate drops back under the threshold with successful traffic in the window, the scheduler closes the incident (and sends a recovery email if enabled). Silence alone never resolves an incident — it stays open until success traffic returns or you close it manually via the dashboard. If failures return, the same incident reopens (reopen_count increments) rather than opening a duplicate.

HTTP Ping monitor

An HTTP Ping monitor is a dashboard-configured endpoint check, independent of any SDK. It is stored as monitor_features(type='http_ping'). The backend pings on intervalMins and stores results in monitor_checks. The number of monitors and the minimum interval are plan-gated — see Reference.

Event vs Run

In the SDK wire format, the word is “event”. On the dashboard and in the public API, the user-facing term is “run”. They refer to the same row in monitor_events — don’t be confused when you see both terms in different surfaces.