Workspace Administration
Usage & logs
Review usage metering, activity logs, application logs, and operational audit history.
Usage & logs
Usage & logs covers tenant observability: usage meters, activity logs, tenant logs, API counters, workflow counts, automation runs, file storage, and Iris usage. Use this page when you are setting up the product surface, reviewing a rollout, or troubleshooting why users see a different result from an administrator.
What this surface is
- Primary purpose: tenant observability: usage meters, activity logs, tenant logs, API counters, workflow counts, automation runs, file storage, and Iris usage.
- Where users start: Account usage is at
/settings/account/usage; activity logs are at/settings/account/activity-logs. - Where administrators configure it: Application-level tenant logs are at
/settings/application/tenant-logs; usage counters are maintained against tenant monthly usage records. - Runtime/detail surface: Admins use these pages to diagnose unexpected changes, review plan limits, and confirm that fixes actually ran.
- Platform connections: Usage data connects API apps, workflows, dashboards, reports, webhooks, files, Iris, and billing governance.
Where it lives
| Area | Path or surface | Use it for |
|---|---|---|
| User surface | Account usage is at /settings/account/usage; activity logs are at /settings/account/activity-logs. | Day-to-day work and review. |
| Configuration | Application-level tenant logs are at /settings/application/tenant-logs; usage counters are maintained against tenant monthly usage records. | Setup, permissions, routing, labels, and behaviour. |
| Runtime/detail | Admins use these pages to diagnose unexpected changes, review plan limits, and confirm that fixes actually ran. | Testing the live experience users actually see. |
Configure it
- Confirm the audience for this surface and whether they are staff users, portal users, customers, public visitors, or administrators.
- Open the owning product route: Account usage is at
/settings/account/usage; activity logs are at/settings/account/activity-logs. - Review the configuration route and permissions before changing live behaviour: Application-level tenant logs are at
/settings/application/tenant-logs; usage counters are maintained against tenant monthly usage records. - Define the primary records, fields, statuses, owners, and notifications involved in this workflow.
- Configure Usage page, Activity logs, and Tenant logs first because they shape the rest of the rollout.
- Add API counters and Automation counters only after the core path works with sample data.
- Test the runtime surface as a restricted user, not only as a superadmin: Admins use these pages to diagnose unexpected changes, review plan limits, and confirm that fixes actually ran.
- Check downstream connections after saving: Usage data connects API apps, workflows, dashboards, reports, webhooks, files, Iris, and billing governance.
- Record the owner, rollout date, and support path for the configuration.
- Review the first week of activity and remove any option that users do not understand or need.
Configuration options
| Option | Use when | Notes |
|---|---|---|
| Usage page | Admins need plan counters and month-to-date activity | Route: /settings/account/usage. |
| Activity logs | Admins need a user/action audit trail | Route: /settings/account/activity-logs. |
| Tenant logs | Admins need application events and integration traces | Route: /settings/application/tenant-logs. |
| API counters | Integrations are active | Review API app count and API call volume. |
| Automation counters | Workflows and jobs are running | Review workflow count and automation runs. |
| Iris counters | AI features are enabled | Review LLM calls and credit usage. |
Operating notes
- Keep labels aligned with the words users see in the product, especially Usage page and Activity logs.
- Permissions still matter even when a menu, page, or link is visible.
- If users see empty data, check role filters, enabled apps, ownership rules, and saved filters before editing records.
- If a change affects customers or public visitors, test from a logged-out or customer account as appropriate.
- Use reports or logs to confirm the change produced the expected operational result.
- Capture configuration decisions in rollout notes so support teams know what changed.
- Do not reuse one option for unrelated processes just because it is already configured.
- Review linked notifications, workflows, dashboards, and reports after changing this surface.
- Prefer narrow changes that can be tested with sample data before a tenant-wide rollout.
- When troubleshooting, start at the route users open, then inspect configuration, permissions, and logs in that order.
- Keep retired settings hidden or archived so users do not choose outdated paths.
- Assign an owner for ongoing review; unattended configuration becomes stale quickly.
For developers
Use these pages when the surface is read or changed by code, scripts, embeds, widgets, API clients, webhooks, or realtime listeners.
- /developer/api-applications-keys
- /developer/realtime-streams
- /reference/system-identity
- /reference/side-effects