This article describes how to view to view the Administrator Logs report using the Administrative UI. The Administrator Logs report provides an audit trail of all administrator actions performed within your account.


  1. Only the Primary Administrator or a User with the Reports role assigned can generate Administrator Logs reports.

Content / Solution:

  1. From the Home screen, click on the Compute menu, and select Download Reports from the drop-down menu:

  2. The Download Reports page will be displayed:


  3. Select "Administration" from the drop-down menu:

  4. The system will ask you to define the Start and End dates for the report. The date range cannot be larger than 31 days. Click "Download" button when you've entered the dates:

    IMPORTANT NOTE: You will need to select an end date one day later than your actual desired end date for audit data. For example, if you want to generate a report showing Administrator Logs for the month of March 2014, your start date should be 3/1/14, but your end date should be 4/1/14.
    Note: a report cannot be generated for greater than a year earlier than the current date (allows for leap years).
  5. The system will download a CSV formatted report that provides the details of every action performed by the organization during the time period selected. Opening up this file in Microsoft Excel or Google Docs is probably the easiest way of understanding the results:

    In this example, the user "cloud" has:

    • Started a Server
    • Shutdown the Server
    • Cloned the Server to become a new Client Image
    • Deployed a new Server from the Client Image
    • Edited the description of the Client Image.

    The columns on the reports are as follows:

    • UUID - uniquely identifies the action in the given report row.

    • Time - refers to the time the action was received by our API tier. All timestamps are in UTC.
    • Create User - identifies the username of the administrator taking the action or OEC_SYSTEM if the action is being taken by the CloudControl system. See the notes below for more information regarding how this field is populated.
    • Department, Customer Defined 1, and Customer Defined 2 - are the current Tag metadata fields associated with the administrator as defined when the user was created or edited. See How to Manage the Primary Administrator User and other Sub-Administrators as the Primary Administrator
      • Note: The Department, Customer Defined 1 and Customer Defined 2 fields reflect the value at the time of the operation, and not at the current time. Meaning that if the values of these fields are changed between the time the audited operation was run and the time that the Administrator Logs report is downloaded, that the values appearing in the of report are those which were correct at the time the operation was run. However, if the user has been deleted from this system, these values will always be populated as "deleted".
    • Type - is the type of object against which the action was taken. 
    • Name - is the name of the object against which the action was taken.
    • Action - is the action that was taken which generated the entry. 
    • Details - provides the details around the specific action that was taken.
    • Response Code - identifies whether or not the action was successful.
      • Note that a REASON_11 value for an asynchronous failure belonging to any API 0.9 or API 2 operation indicates a clean failure that can safely be retried.


    1) The number of rows per action can differ.

    Each action taken by an administrator on your account is represented by at least one row on the report. For example; an edit of a Network name or description will be displayed as a single row log entry. However, most actions will have two rows associated with the action:

    • The first entry will have the username associated with the requestor populated under "Create User" column. This row represents the "request" by the user to perform the action via the Admin UI or API.
    • The second entry will have the "OEC_SYSTEM" field populated in the "Create User" column. This row represents the actual success or failure to implement the action by the CloudControl system.

    2) What are the OEC_SYSTEM actions of "Remote Stop Server" or "Remote Start Server"?

    These entries indicate that the CloudControl system identified that a virtual machine's running state was different than that recorded in the system database. The background to this entry is:

    • It is possible for servers to be stopped/started independent of actions taken in the Admin UI or API. For example, someone logged into a server may stop or restart the machine locally. 
    • Therefore, CloudControl checks the running status in the hypervisor of every Cloud Server within a five-minute interval. When the status of the server as reported by the hypervisor differs from the status in the CloudControl DB, the system updates itself to reflect the running state as reported by the hypervisor. Such changes are logged with the "Remote Stop Server" or "Remote Start Server" populated in the "Create User" column. The primary reason for this reconciliation is to ensure billing accuracy. If someone stops the server locally, the system will pick up that event and stop billing CPU and RAM hours for the affected server.
    • It is important to note these actions DO NOT indicate the system is making any changes to the actual running state of the Cloud Server - i.e. the system is NOT taking actions to start or stop your server. Instead, the system is merely updating itself to reflect the current state of the server as reported by the hypervisor.