- Getting started
- Data security and compliance
- Organizations
- Authentication and security
- Licensing
- Tenants and services
- Accounts and roles
- External applications
- Testing in your organization
- AI Trust Layer
- Notifications
- Logging
- About logs
- Exporting logs
- Troubleshooting
- Migrating to Automation Cloud Dedicated
Automation Cloud Dedicated admin guide
A log is an array of data ordered by time that follows the "first in, first out" rule. That means the oldest log entry is the first one deleted at the end of the retention period. Logs help with debugging issues, increasing security and performance, or reporting trends.
Cloud Portal and cloud services are using different types of logs to help with debugging issues, increasing security and performance, or reporting trends.
Audit logs are a special type of logs that help to gain insight into events that happened within your organization. It answers the who, when, and where for every event, and it allows you to keep track of important changes.
When extracting audit logs, only the last 5000 entries are downloaded.
Organization administration
The Audit Logs page captures actions performed from the Admin pages and log in activity for the organization. This includes user log in activity, license upgrades, any changes made to your tenants, refresh of an API key, and more.
As the organization administrator, you can view the audit logs by going to Admin > Organization > Audit Logs.
Each audit log entry is kept for approximately 30 days in the case of Community accounts, and for two years for Enterprise.
To keep the logs beyond this limit, we recommend to periodically archive them as CSV files to your local storage. Select Download to export the audit logs.
Automation Ops
Audit logs for the Automation Ops service are also displayed in the Admin > Organization > Audit Logs page.
This section describes the classic audit experience log actions recorded for Automation Ops, specifically for the Governance, Manage Feeds, Pipelines, and Source control audit sources. For each action, the following table lists what action is logged and the captured information:
|
Category |
Action |
Description |
Logged Information |
|---|---|---|---|
|
Governance |
Create Policy |
A user successfully creates a new policy. |
Policy name, product name, policy data, priority, availability. |
|
Governance |
Edit Policy |
A user successfully edits an existing policy. |
For both the original policy and the edited policy: name, product name, policy data, priority, availability. |
|
Governance |
Upload Policy |
A user successfully uploads a policy. |
Policy name, product name, policy data, priority, availability. |
|
Governance |
Delete Policy |
A user successfully deletes a policy. |
Policy name, product name, policy data, priority, availability. |
|
Governance |
Deploy To Tenant |
A user successfully deploys one or more policies at tenant level. Each per-product edit is tracked in a separate log, regardless of whether or not it is the result of a bulk action. |
Policy name or No policy / Inherit, license name, product name, tenant name. |
|
Governance |
Deploy To Group |
A user successfully deploys one or more policies at group level. It includes all actions that can affect the deployment settings:
Each per-product edit is tracked in a separate log, regardless of whether or not it is the result of a bulk action. |
Policy name or No policy / Inherit, license name, product name, group name. |
|
Governance |
Deploy To User |
A user successfully deploys one or more policies at user level. It includes all actions that can affect the deployment settings:
Each per-product edit is tracked in a separate log, regardless of whether or not it is the result of a bulk action. |
Policy name or No policy / Inherit, license name, product name, user name. |
|
Governance |
Edit Version |
A user performs a successful upgrade / downgrade of a policy template Each per-product edit is tracked in a separate log, regardless of whether or not it is the result of a bulk action. |
Product name, old template version, new template version (major.minor.patch). |
Orchestrator
The audit from the Orchestrator service lists all the events linked to a specific tenant. You can notice folders or machines creations, packages uploads, roles assignments, or settings updates. Simply put, every step that may influence the orchestration process is captured inside the Orchestrator's Audit page.
You need to be an Administrator to access the Audit page at the tenant level.
The audit logs are retained for six months in the case of the Community plan, and for two years for Enterprise.
To keep your logs beyond these limits, you can export them to your local storage.
Learn more about the audit logs at Orchestrator's tenant level.
The robot logs found at Orchestrator's folder level are useful to monitor the executions of every robot from a specific folder.
You need the specific folder permission to manage the logs .
Robot logs are kept for a maximum of 31 days by Orchestrator.
If you need these logs for longer, you can periodically export logs to:
- your local storage
- third-party cloud storage.
For instructions, refer to Exporting logs.