Skip to main content
IMHCloud Logo
Back to support home

Understanding Instance Action History in OpenStack

Compute

Introduction

Every action performed on an OpenStack instance gets logged automatically. This action history provides a complete audit trail of what happened to your instance, when it happened, and who initiated the action. Whether you are troubleshooting an issue, investigating unexpected behavior, or maintaining compliance records, the instance action log is an essential tool for cloud operations.

The action log tracks operations like creating, starting, stopping, resizing, and deleting instances. It records both successful operations and failed attempts, giving you visibility into the full lifecycle of your virtual machines.

What Gets Logged

OpenStack Nova automatically records every API request that affects an instance. The action log captures:

  • Instance lifecycle operations: Create, start, stop, pause, unpause, suspend, resume, shelve, unshelve, delete
  • Resource modifications: Resize, rebuild, migrate, evacuate
  • Configuration changes: Attach/detach volumes, modify security groups, update metadata
  • Recovery operations: Reboot (soft and hard), rescue, restore
  • Network operations: Attach/detach interfaces, assign/remove floating IPs
  • Snapshot operations: Create image, backup

Each log entry includes the action name, request ID, timestamp, user who initiated the action, project ID, and the result (success or failure with error details).

Viewing Instance Action History

Using Horizon Dashboard

The OpenStack Horizon dashboard provides a visual interface to review instance actions:

  1. Navigate to Project > Compute > Instances
  2. Click on the instance name to view details
  3. Select the Action Log tab
  4. Review the chronological list of all actions performed on the instance

The action log displays the most recent actions first. Each entry shows the action type, user, request ID, start time, and status.

Using OpenStack CLI

For command-line access and automation, use the OpenStack CLI to retrieve action history:

List all actions for an instance:

1openstack server event list <instance-name-or-id>

This returns a table showing:

  • Request ID (unique identifier for the operation)
  • Server ID
  • Action (operation type)
  • Start Time
  • Message (result or error information)

Get detailed information about a specific action:

1openstack server event show <instance-name-or-id> <request-id>

This displays complete details including the project ID, user ID, exact timestamps, and any error traceback if the operation failed.

Using the Nova API Directly

For programmatic access and integration with monitoring tools, query the Nova API:

List actions:

1curl -X GET \
2  https://your-openstack-api/compute/v2.1/servers/<instance-id>/os-instance-actions \
3  -H "X-Auth-Token: <your-token>"

Get action details:

1curl -X GET \
2  https://your-openstack-api/compute/v2.1/servers/<instance-id>/os-instance-actions/<request-id> \
3  -H "X-Auth-Token: <your-token>"

The API returns JSON responses with complete action metadata, making it easy to parse and integrate into custom dashboards or alerting systems.

Understanding Action Log Entries

Each action log entry contains structured information that helps you understand exactly what happened.

Request ID: A unique UUID that identifies the specific operation. This request ID correlates with OpenStack service logs, allowing you to trace the operation across multiple components.

Action Name: The operation type, such as create, reboot, resize, delete. Action names follow a consistent naming convention that reflects the API operation.

Start Time: When the action was initiated. Timestamps use UTC by default and include microsecond precision for accurate sequencing.

User ID and Project ID: Identity information showing who requested the action and under which project context. This provides accountability and helps with access auditing.

Status/Message: The outcome of the operation. Successful actions show a completion message. Failed actions include error codes and detailed traceback information that explains why the operation failed.

Common Use Cases

Troubleshooting Failed Operations

When an instance operation fails, the action log provides immediate diagnostic information. You can see the exact error message, the time the failure occurred, and the sequence of events leading up to the failure.

For example, if a resize operation fails, the action log shows whether the failure happened during scheduling, resource allocation, or the actual resize process. Error messages include details like insufficient capacity, quota exceeded, or resource conflicts.

Investigating Unexpected Instance State

If an instance is in an unexpected state (stopped when it should be running, or missing entirely), the action log reveals what happened. You can see who performed the action and when, whether it was intentional or accidental.

This is particularly valuable in shared environments where multiple team members have access. The log provides a clear timeline of all state changes.

Compliance and Security Auditing

Many compliance frameworks require detailed audit trails of infrastructure changes. The instance action log provides this automatically, recording every modification with user attribution and timestamps.

Security teams can use the action log to detect unauthorized access attempts, unusual patterns of activity, or policy violations. For example, you can identify if someone attempted to delete production instances outside of approved maintenance windows.

Performance Analysis

The action log helps correlate instance operations with performance issues. If users report degraded performance, you can check whether any resize, migration, or configuration changes occurred around that time.

The precise timestamps allow you to overlay action history with monitoring data from other tools, creating a complete picture of what was happening when performance changed.

Action Log Retention

OpenStack stores action logs in the Nova database. The retention period depends on your OpenStack deployment configuration. By default, action logs remain available indefinitely unless explicitly purged.

For long-term retention and compliance requirements, export action logs to external systems. Most organizations implement automated log collection that sends action data to centralized logging platforms like Elasticsearch, Splunk, or cloud-native logging services.

Some deployments configure database archival policies that move older action logs to separate storage after a retention period (commonly 90 days or 1 year). This keeps the active database performant while preserving historical records.

Action Log vs. Other OpenStack Logs

The instance action log differs from other OpenStack logging mechanisms:

Instance Action Log: Records high-level operations performed on instances through the Nova API. This is user-action focused and answers "what operations were requested and by whom."

Service Logs: Each OpenStack service (Nova, Neutron, Cinder) maintains detailed operational logs that capture internal processing. These logs show how services executed operations and are used for debugging infrastructure issues.

Audit Logs: Some deployments enable additional audit logging middleware that captures all API requests across OpenStack services. This provides broader visibility but requires additional configuration.

The instance action log is the most accessible and user-friendly option for tracking instance-specific operations. It requires no additional configuration and is available in every OpenStack deployment.

Filtering and Searching Action History

When working with instances that have extensive history, filtering becomes important:

Filter by action type:

1openstack server event list <instance> | grep reboot

Filter by date range:

1openstack server event list <instance> --since "2026-01-01"

Export to CSV for analysis:

1openstack server event list <instance> --format csv > instance-actions.csv

For advanced filtering and analysis, query the Nova database directly (requires admin access):

1SELECT * FROM instance_actions
2WHERE instance_uuid = '<instance-id>'
3  AND created_at > '2026-01-01'
4ORDER BY created_at DESC;

Best Practices

Regular Review: Establish a practice of reviewing action logs during troubleshooting. Check the action log first when investigating any instance issue. This saves time by quickly identifying recent changes that might explain unexpected behavior.

Automated Monitoring: Integrate action log data into your monitoring stack. Set up alerts for sensitive operations like deletions, security group changes, or repeated failed actions that might indicate problems.

Access Control: Implement proper role-based access control (RBAC) so that action logs show meaningful attribution. When every operation shows the same service account, the audit value decreases significantly.

Retention Planning: Define retention policies based on compliance requirements. Export and archive action logs before they are purged from the production database.

Request ID Correlation: When reporting issues to support or investigating complex problems, always include the request ID from the action log. This allows support teams to correlate your instance action with backend service logs for faster resolution.

Limitations and Considerations

Administrative Actions: Some administrative operations performed directly at the hypervisor level (outside the OpenStack API) may not appear in the instance action log. These operations bypass Nova and therefore are not tracked in the standard action history.

Read-Only Operations: The action log records state-changing operations. Read operations like listing instances, viewing instance details, or querying status are not logged in the instance action log (though they may appear in API audit logs if configured).

Deleted Instance History: When an instance is deleted, its action log is retained for a period defined by your OpenStack deployment. However, the action log may eventually be archived or purged. Export important audit trails before deleting instances if long-term retention is required.

Performance at Scale: In environments with hundreds of instances and frequent operations, querying action logs across many instances can be slow. Use filters and limit queries to specific instances or time ranges for better performance.

Conclusion

The OpenStack instance action log provides essential visibility into everything that happens to your virtual machines. It answers the critical questions of what happened, when, and who initiated it. By understanding how to access and interpret action logs, you gain powerful tools for troubleshooting, auditing, and maintaining operational awareness.

Whether you are investigating a failed operation, tracking down unexpected changes, or maintaining compliance records, the instance action log is your first resource. Make it a standard part of your OpenStack operations workflow.