Omaya docs

Appearance

Who did what: Activity Log and Usage ​

Three pages answer "what happened?". The Activity Log says who changed what, who signed in, which commands went to devices, and what the system did on its own. Usage says how many messages, AI tokens, webhooks and alerts your organisation used in a month, and which messages failed. SLA & Uptime gives the service level over a period.

PageMenu and addressPermissionAs shipped
Activity LogSystem › Activity Log, /admin/activityView Audit TrailAdmin, Manager
UsageSystem › Usage, /admin/usageView Platform UsageAdmin, Manager, Viewer
SLA & UptimeSystem › SLA & Uptime, /admin/system/uptimeView ConfigAdmin, Manager

See Roles and permissions to give them to someone else.

The Activity Log ​

What is recorded ​

Everything is in one list, in the order it happened. Full timeline (where the page opens) shows all of it except page views; Needs a look keeps only what deserves a second glance. In the timeline, the lanes over the list narrow it to one kind of row. The count on a lane is for the last 7 days, whatever dates you have chosen.

LaneWhat is in it
EverythingThe page opens on this one: everything except page views
PeopleWhat administrators and app users did. Inside it: Changes (adding, changing, removing or restoring a record: rules, gateways, devices, zones, venues, locations, people and assets, roles, administrators, scheduled reports, outbound webhooks, work orders, panic buttons, connectors (which fields changed and whether it was switched on or off, never the values), settings (the old and new value; a password or key only by name), and the apps' own records such as bookings, visits and incidents; a change keeps the old and new value of each field that changed), Deletions (only the records removed, with their last values), Sign-ins (signing in and out, failed sign-ins, failed or locked-out two-step codes, sign-in links sent or refused, on the admin console and in the apps) and In the apps (everything an app user did in a mini app or the mobile app, below)
DevicesEvery command sent to a device: who or what sent it, and how it went
SystemWhat happened with nobody at the keyboard: a gateway going offline and coming back, a device going silent and recovering, a battery falling to low or critical, a zone going over capacity and back under, a scheduled report that failed, an app's schedule paused, an outbound webhook that gave up, a connector that started or stopped failing, and the nightly check finding a record that has been altered
AI assistantWhat OAIA changed, on someone's say-so or on autopilot
Page viewsAn administrator opening certain pages, such as Roles or the Activity Log itself

Needs a look holds deletions; failed or blocked sign-ins and failed two-step codes; password changes (their own, from a Forgot password link, or one administrator setting another's); administrator accounts added, removed, switched off or given another role (also by single sign-on groups); role changes; device commands that failed, timed out or were refused; and system events at warning or error level (a gateway offline, a device silent, a connector failing, a battery low). The Needs a look tile opens it.

Platform staff who open your organisation to help appear under their own username, and so do changes they make to your organisation's settings from the platform side, such as its gateway-health thresholds. Actions taken by OAIA are shown as oaia/ followed by the person it acted for, or oaia/autopilot.

What is not recorded ​

  • What an app user typed. The In the apps tab records the action and the record it was about, never the form's contents: a note can hold a name, an ID number or a password.
  • An app user just looking. Opening pages in a mini app is not recorded; only changes are.
  • A change to only a rule's condition or action. The rule's own settings are recorded (its name, priority, what it watches, Checked, Days, Hours, Repeat at most every and the On switch), but changing just a threshold, a message or an address does not get a row of its own at the moment.
  • Messages that went out. Who was emailed or messaged is on Usage and on Live Monitor's Rules tab, not here.

How long it is kept ​

The log is kept in monthly blocks and a whole month is deleted once it is older than your retention period. The period is Audit log on the Data Retention card of System › Configuration (it needs Manage Tenant Settings). Left blank it is 30 days; whatever you set, at most 120 days are kept, even though the box accepts more and its hint mentions a year. With 30 days you always have at least the last 30 days, plus the rest of the month the oldest of them fell in. Export what you must keep longer.

Reading the page ​

How to read one row of the Activity Log A sample row, under its day heading: at 02:14 on 13 October, Ravi Kumar updated rule number 12, from IP address 203.0.113.24. When is shown on your organisation's clock, as in the exports. Event is the kind of row: a change, a sign-in, a command or a system event. Actor is the admin, an app user marked app, or system. What says the change in words, with ×3 when the same person did the same thing again within ten minutes. IP says where the request came from; the page it was made on is in the detail. Clicking the row opens Event detail: the subject and tags, Old vs New showing only the fields that changed, for example action_every from 3600 to 300, and a SHA-256 checksum that is either verified as unchanged since it was written or shown as not matching. ONE ROW · SYSTEM › ACTIVITY LOGWHENEVENTACTORWHATMODULEIP13 Oct 02:14updatedRavi Kumarupdated rule #12—203.0.113.24123451 When: your organisation's clock, the same in the CSV and PDF exports.2 Event: the kind of row (a change, a sign-in, a command, a system event); the lanes filter on it.3 Actor: the admin, an app user marked (app), or system when nobody did it by hand.4 What: in words, e.g. rule #12; ×3 when repeated within 10 min; a system row also says how it ended.5 IP: where the request came from. The page it was made on is in the detail.CLICK THE ROW · EVENT DETAILEventWhen · Actor · Subject · TagsRequest: URL, IP address,user agentOld vs Newaction_every3600 → 300only the fields that changedSHA-256 checksum✓ verified: unchanged sinceit was written✗ does not match: changed
The row says who, when and roughly what; the detail says exactly what. For a change to a setting, Old vs New is the evidence: 3600 seconds to 300 is "repeat at most every hour" becoming "every five minutes".
  1. Open System › Activity Log (/admin/activity). The page is headed Activity Log, Everything that happened in your workspace, in order: what people did, commands sent to devices, and what the system and the AI assistant did on their own. Under it: how many people were active in the last 7 days and who was most active, and when the last integrity check ran, for example All 12,538 records unchanged · checked 6h ago (see Integrity).
  2. Last 7 days: five tiles, Needs a look (with how many were deletions), People (changes and sign-ins), Devices (commands sent), System and AI assistant. Click a tile to open its list.
  3. Date range: two date boxes, and Today, Last 7 days, Last 30 days and Last 90 days. It opens on the last 7 days, on your organisation's calendar.
  4. The search box, Search record, page address, IP…, matches the page address, the kind of record, the IP address, and the old and new values. It does not match a person's name or username: to see one person's actions, click their name (step 9).
  5. Full timeline or Needs a look (see What is recorded).
  6. In the timeline, the lanes: Everything, People, Devices, System, AI assistant and Page views. People shows a second row: All, Changes, Deletions, Sign-ins and In the apps.
  7. Per day: a bar for each day of the range, coloured by lane (people, devices, system, AI assistant). Hover a bar for its numbers; click it to show only that day, and click it again to go back to the last 7 days.
  8. The list: When, Event, Actor, What, Module, IP, newest first, with a heading for each day (Today, Yesterday, then the date). What says it in words, such as updated rule #12, updated company member #464 — Visitor or signed in — admin console, with durations and times on your organisation's clock. The same person doing the same thing again within ten minutes is one row with ×N beside it. Under a change, the first three fields that changed, such as On: off → on · repeat at most every: 1 h → 5 min, with +N more when there are others; saved, nothing changed when it was saved as it was. Passwords and other secrets say only changed, and a rule's flow layout or a zone's shape moved or redrawn. The link icon after What opens the record itself, for example the rule. 25 rows a page; the foot of the list says Showing 1–25 of N events.
  9. Click a name in Actor to show only that person. A chip Only name appears beside the dates; its × shows everyone again. Their rows are grouped into sessions instead of days, 100 a page: a sign-in starts one, and so does a break of more than 30 minutes. Each heading says when it started and ended, how many events, whether they signed out, the IP address and the browser, for example Session · Signed in 20-Oct-2026 15:40 – 16:12 · 12 events · signed out · IP 202.185.98.203 · Chrome on macOS.
  10. Click any other part of a row for Event detail: Event (type, when, actor, subject, tags), Request (URL, IP address, user agent), Changes as a table of Field, Was and Now (the values as stored are under Stored values), and the record's SHA-256 checksum, with ✓ verified: unchanged since it was written or ✗ does not match: this record was changed after it was written.

Refresh at the top right reloads the tiles, the chart and the list.

How it ended ​

A system row that something went wrong says underneath how it ended:

RowUnderneath
A gateway went offlineback online 15:31 · 26 min, or still offline
A device went silentreporting again 17:00 · 4 h, or still silent
A connector started failingworking again 19:58 · 53 s, or still failing
A zone went over capacityback under capacity …, or still over capacity

The row for the recovery says how long it lasted, for example was silent for 4 h. Both rows stay where they happened in the timeline. Still means nothing has happened to it since, so it is still out now.

History on a record ​

Four pages show a record's own rows from the last 90 days, newest first, with Open in Activity Log to see them here (the page then shows a chip Onlyname):

WhereWhat it shows
Device › Sensor, a device's panel, History tabChanges to it, commands sent to it, and when it went silent, recovered or ran low on battery
Device › Gateway, a gateway's panel, History at the bottomChanges to it, and when it went offline and came back
Rules, the rule editor, HistoryWho created and changed the rule, and when
System › Admins, an administrator's panel, History at the bottomWhat they did, and changes to their account

Each needs View Audit Trail; without it the History tab or section is not shown.

Integrity and exports ​

Every record gets a SHA-256 checksum when it is written. Each night every record is checked against its checksum (ISO 27001 A.12.4.2), and the line under the title says when that last ran and whether anything had changed. A changed record also adds a row on System.

Export CSV and Export PDF at the top right export what the list is showing: the same dates, view, lane, search, person and record. Both use your organisation's clock and the words the list uses, and check every exported record against its checksum again:

  • The CSV has every row, with Record, When, Event, Who, What, Subject, IP, URL and Unchanged since written (yes or NO), then how many records were unchanged and a Fingerprint.
  • The PDF has When, Who, What, IP and OK (✓ or ✗), and above the table the filters, N records · every one unchanged since it was written (or which ones were changed), the Fingerprint, and who exported it when. It stops at 500 rows and says so; use the CSV for more.

The fingerprint is a SHA-256 of the exported records' checksums, in order. Export the same range again later: the same fingerprint means the same records, unchanged.

A weekly access review ​

System › Schedule Report, report Access Review, emails who can get into the console and what changed about that over the period (pick 7 days for a weekly review):

SectionWhat it lists
AccountsAdministrators added, removed, switched off or on, given another role, two-step turned on or off, and by whom
RolesRoles created, changed or removed, and by whom
Failed sign-insPer account and IP address, how many tries and the last
DeletionsRecords deleted, per kind and person
Dormant (no sign-in for 30 days)Active administrators who have not signed in for 30 days
No two-step sign-inActive administrators without two-step sign-in
Activity Log integrityThe last nightly check: how many records, and whether any had changed

It is offered only to roles with View Audit Trail, and sent only to chosen administrators who have it.

What app users do ​

Every change an app user makes in a mini app or the mobile app that the server accepts is one row under In the apps: who, when, from which IP, and the action named in words, such as created work orders — Facility or acknowledged incident — Security Watch, with the first characters of the record's ID. A change made in the mobile app ends in (mobile app). The detail's New values has the app, the action and the record. Their sign-ins are on this tab too, and on Sign-ins. Refused requests (an error, no access) are not recorded.

Daniel Lim, a technician, says he closed the lift-lobby job on Tuesday. Open People › In the apps, set both date boxes to Tuesday, and click his name in Actor (app users are marked (app)) to see only his rows.

Who changed this rule? ​

The Server Room rule used to email once an hour; since Thursday it emails every half minute.

The quickest way: open the rule (Rules, then the rule) and click History in the editor. Each row is a change with who and when; Open in Activity Log shows them on the full page, where a row opens its detail (step 6). Or from the Activity Log itself:

  1. Open System › Activity Log.
  2. Set Date range to cover when it started: Last 7 days.
  3. Click People, then Changes.
  4. Type rule in the search box. The rule changes are left, with any other change whose page address or values mention a rule.
  5. Each row reads updated rule #12, or updated rule "Server Room" when the name itself was changed, with the Actor and When. The link icon after it opens the rule. Click the row.
  6. The line under the row, and Changes in the detail, show the fields that changed in words: repeat at most every: 1 h → 30 s, On: on → off, from and until for Hours. The name is in the values when it was changed; otherwise match the number (#12) across rows, or use the link icon to see which rule it is.

A rule that was deleted shows under Deletions with all its last values. If the change was only to a threshold or an action, there is no row for it (see What is not recorded).

Did the SMS go out? ​

Ravi's rule should have texted the on-call engineer at 02:10.

  1. Monitor › Live Monitor (/admin/monitor), the Rules tab: find the firing at 02:10. No row means the rule did not fire; see Why did I get 40 emails (or none)?.
  2. On the row, the SMS action's badge says sent (the SMS provider accepted it), skipped with the reason (No active SMS connector, No recipient set) or failed with the provider's error. Hover it for the full text. A skipped SMS never reached the provider, so step 3 will not list it.
  3. System › Usage, the current month: Needs attention groups the failed messages by cause, and the Failed tab lists the last ten refusals with the time, the masked number and the provider's error. A failure at 02:10 there is your answer.
  4. Sent with no failure means the provider accepted it. If it still did not arrive, the number or the provider is the next thing to check: send a test from the SMS connector under Connectors.

Usage never shows the message text, and shows each number masked.

Who signed in at 2am? ​

  1. Open System › Activity Log.
  2. Set both date boxes to the night in question.
  3. Click People, then Sign-ins. It holds the admin console and the apps together. Failed sign-ins are also under Needs a look.
  4. Each row says, for example, signed in — admin console or failed to sign in — tenant app (bad password), with the Actor and IP, newest first.
  5. Click the row for the detail: the IP Address, and for the admin console the User Agent (which browser).
  6. To see what that person did next, click their name in Actor, then Everything with the same dates.

A failed sign-in with a username or address that has no account shows system as the actor, with what was typed in New values.

What happened overnight? ​

Click the System tile, or System in the timeline, and set the range to last night. Gateways that went offline and came back, devices that went silent, a scheduled report that failed to send, a connector that started failing: each is one row, written when it changed, not every minute it stayed that way. A gateway row reads like Gateway L3 East went offline (last heard 20-Oct-2026 19:42), with back online 20:08 · 26 min underneath, or still offline if it has not come back. To see only what is still wrong, or went wrong at all, use Needs a look.

Who sent a command to a device? ​

Click the Devices tile, or Devices in the timeline. Each row is one command: what it was, to which device, and who sent it, an administrator or the rule that sent it by name. For one device, open its History tab in the device panel. See Device settings and commands.

Usage: your plan, messages, AI and data ​

System › Usage (/admin/usage) is headed Omaya Platform Usage, What was used in the month, how it compares with the month before, and anything that did not get through. It shows counts, not money: there are no prices or credits on it.

  1. Pick the month in the list at the top right. It opens on the current month. Export CSV beside it downloads that month as one spreadsheet: the plan, AI by feature, messages, webhooks, alerts, data in per connector, people, scheduled reports and API keys.
  2. Needs attention comes first. Failed messages are grouped by channel and cause, for example 12 SMS messages did not go out, with the provider's reason, how many recipients and when the last one was, and Check the connector, which opens Connectors. Failed webhook deliveries have Check the webhook, and AI at 80% or more of the month's allowance is listed too, as are: active devices at 90% or more of what your plan includes, a scheduled report whose last send failed (Open Schedule Report), API keys expired or expiring within 30 days, and ten or more failed sign-ins in the month (Open the Activity Log). With nothing to report it says Everything got through.
  3. Your plan: the plan's name, Active devices (against what the plan includes, with a bar, or no device limit on your plan), Active gateways, Apps switched on, the AI allowance on Omaya's key, and History kept (how many days of readings and trails are kept).
  4. The tiles, headed So far this month · day N of N or The whole month: AI tokens (with the share of the monthly allowance on Omaya's key used, when there is an allowance, or all on your own key), Messages sent, In-app alerts and Webhooks delivered. Each is compared with the month before, for example ▲ 12% vs September or about the same as September. Click AI tokens or Messages sent to open its tab.
  5. Messages tab: SMS, WhatsApp, Email, Telegram, Slack and Microsoft Teams, each with the number sent and failed (SMS also in segments), a chart per day, and What they were for: Rule alerts, Report deliveries, One-time codes, Verification links, Portal mail, App modules, Security Watch, Connection tests, Other. The line at the foot says how many e-mails went out through Omaya's mailer and how many through your own mail server (your own SMTP connector; Omaya's mailer is used when you have none enabled).
  6. AI tab: the allowance on Omaya's key as a bar; What used it, the tokens and requests of each feature (Assistant (questions), Briefings and suggestions, AI Reporting, Rule drafts (Describe it), New sensor types, Positioning advisor, and the apps that use AI); and By provider, under Omaya's key and Your own key, with Requests and Share. The split by feature starts in October 2026; earlier months show providers only. Your own key is not capped by Omaya. With no allowance set it says No monthly cap is set for this tenant's shared-service use.
  7. Data in tab: messages received from your gateways this month, per day, and per gateway connector with the number of days anything arrived. A connector that is on but received nothing is marked nothing received. Counted from 19 October 2026.
  8. People tab: Admins who signed in (of your active admins), Admin sign-ins, App users active (of your app users) and Failed sign-ins, each against the month before.
  9. Reports tab: scheduled reports sent and failed this month, schedules on and paused, and any schedule whose last send failed, with its error.
  10. API tab: each API key with its calls this month, when it was last used, and when it expires; keys unused for 90 days, expiring soon or expired are marked. Calls are counted from 19 October 2026. Keys are made under My Profile → API keys.
  11. Failed tab: the last ten messages that failed this month, with the channel, purpose, time, masked recipient, provider and error. No failed messages this month. when there are none.

A message is counted when Omaya hands it to the provider. One the provider takes and later fails to deliver is counted as sent; a message that never got as far as a provider (a rule's Telegram action with no Telegram connector) is not counted at all.

E-mail to a placeholder address (one at example.com, example.org or example.net, or ending in .test or .invalid) is never sent: such addresses cannot receive mail and are usually test data. It is counted on its channel as not sent to placeholder addresses, not as a failure. Where Omaya recognises a provider's refusal it says what it means in plain words, with the provider's own message underneath.

SLA & Uptime ​

System › SLA & Uptime (/admin/system/uptime) is headed SLA & Uptime, How reliably gateways, devices and rules worked over the last 30 days, with your organisation's name.

  1. Choose 7 days, 30 days or 90 days at the top right. It opens on 30 days.
  2. Four tiles for that range:
    • Gateway uptime: the share of the time each gateway's data was arriving, taken from the gateway outage log, with the number of outages and how long they lasted in total. A site power or network cut counts as down too. A gateway added during the range counts from when it was added.
    • Online now: how many gateways are sending at this moment, N of N.
    • Devices heard in 24 h: devices heard from by any reading in the last 24 hours, of all your devices, with the percentage and see the silent ones, which opens the Devices page on the silent ones.
    • Rule actions that worked: the share of rule actions that completed, with how many worked and failed and how many rules are on.
  3. Gateways: each gateway with Now (Online, Late or Offline), its Uptime over the range as a bar and a percentage, Outages, and Last heard. The lowest uptime is at the top. Click a gateway's name for its outages, or Every outage for all of them.
  4. Rule actions per day: a chart of the actions that worked and failed.

If the outage log started after the beginning of the range, the page says Outages are recorded from that date, and time before it counts as up.

For an availability figure to hold a contractor to, to the minute and per gateway, use Reports › Gateway Availability, which Every outage opens; see Being told when a gateway drops.

Questions and problems ​

The search box does not find a colleague by name. It searches addresses, record types, IPs and changed values, not who did it. Click their name in the Actor column instead: the list then shows only them. For an administrator, their panel under System › Admins has the same History.

A month I need has gone. It was older than the retention period and has been deleted; it cannot be brought back. Raise Audit log on the Data Retention card (up to 120 days are kept) and export anything older you must keep.

An export from before 20 October 2026 has times eight hours out. Exports were in UTC until then; they now use your organisation's clock, named in the CSV's When heading.

A row says ✗ does not match. The row was changed after it was written, which should never happen. Export it and tell your Omaya contact; the nightly check also adds a row on the System tab when it finds one.

A page view I expected is not in the list. The timeline leaves page views out. Use the Page views lane.

The counts on the lanes do not match the list. The lane counts are always for the last 7 days; the list follows the dates you chose.

A gateway row says still offline, but the gateway is back. The row says what the log knows: no "back online" row has been written for it since. Check the gateway's panel under Device › Gateway; if it is online there, the recovery was not recorded (for example during a platform restart).

Activity Log is not in the menu. The role lacks View Audit Trail. Viewer does not have it as shipped.

→ Roles and permissions · Your first rule · Administration menu

Last updated:

Omaya platform documentation

Synchroweb