The Audit Log System: How Deployxa Tracks Every Action
Every action on Deployxa is logged: deployments, environment variable changes, domain additions, rollbacks, container restarts, and MCP tool calls. This audit trail is essential for security (detecting unauthorized changes), compliance (proving who did what and when), and incident investigation (reconstructing what happened during an incident). Here is how the audit log system works, what it tracks, and how to use it.
The direct answer is that Deployxa's audit log system records every state-changing action with the following metadata: timestamp, action type, actor (user or agent), target (which app or resource), parameters, result, and IP address. The logs are stored in an append-only database (entries cannot be modified or deleted), which ensures the audit trail is tamper-proof. The logs are accessible via the dashboard and the MCP server (via deployxa_get_audit_log), and they can be exported to external log management systems for long-term retention. For more on security, see our article on securing agentic cloud deployments.
What the Audit Log Tracks
The audit log tracks the following action types:
1. Deployments
Every deployment is logged, including the app ID, the Git commit hash, the build status (success or failure), the readiness grade, and the deployment URL. This lets you see the complete deployment history for each app.
2. Environment variable changes
Every environment variable change is logged, including the app ID, the variable name, the old value (redacted for secrets), the new value (redacted for secrets), and the actor. This lets you see who changed what and when, which is essential for debugging configuration issues.
3. Domain additions and removals
Every domain addition and removal is logged, including the app ID, the domain, and the actor. This lets you see the domain history for each app.
4. Rollbacks
Every rollback is logged, including the app ID, the release that was rolled back from, the release that was rolled back to, and the actor. This lets you see the rollback history for each app.
5. Container restarts
Every container restart is logged, including the app ID, the reason (e.g., deployment, health check failure, manual restart), and the result. This lets you see the restart history for each app.
6. MCP tool calls
Every MCP tool call is logged, including the tool name, the parameters, the result, the OAuth token ID (which identifies the agent), and the AI assistant that initiated the call. This lets you see what your AI agents are doing, which is essential for security and accountability. For more on MCP audit logs, see our article on how to audit your AI agent's cloud actions.
Step-by-Step: How an Audit Log Entry Is Created
Here is how an audit log entry is created for a typical action (e.g., a deployment).
Step 1: The action is initiated
A user (or agent) initiates a deployment via the dashboard (or the MCP server).
Step 2: The system records the action
The system creates an audit log entry with the following metadata:
- Timestamp: 2026-09-12T12:00:00Z
- Action type: DEPLOY
- Actor: [email protected] (or agent:cursor for MCP calls)
- Target: app:123
- Parameters: { "commit": "abc123", "branch": "main" }
- IP address: 1.2.3.4
Step 3: The action is executed
The system executes the deployment (build, container start, readiness check, traffic swap).
Step 4: The system records the result
The system updates the audit log entry with the result:
- Result: { "status": "success", "readiness_grade": "A", "url": "https://my-app.deployxa.app" }
Step 5: The entry is stored
The audit log entry is stored in the append-only database, where it cannot be modified or deleted.
How to Use the Audit Log for Incident Investigation
Here is how to use the audit log to investigate a production incident.
Step 1: Identify the incident time
Determine when the incident started (e.g., "users started seeing 500 errors at 2 PM").
Step 2: Query the audit log
Query the audit log for actions around the incident time:
deployxa audit-log --app my-app --after "2026-09-12T13:00:00Z" --before "2026-09-12T15:00:00Z"Step 3: Review the actions
Review the actions in the time window. Look for:
- Deployments (did a deployment happen just before the incident?)
- Environment variable changes (did someone change a critical variable?)
- Rollbacks (did someone roll back to a broken version?)
- Container restarts (did the container restart unexpectedly?)
Step 4: Identify the root cause
Based on the audit log, identify the root cause. For example, "a deployment at 1:55 PM introduced a bug that caused 500 errors starting at 2 PM."
Step 5: Take corrective action
Based on the root cause, take corrective action (e.g., roll back to the previous version, fix the bug and redeploy).
Common Pitfalls and Troubleshooting
The first pitfall is not checking the audit log during incidents. Many developers skip the audit log and try to diagnose issues from logs and metrics alone, which misses configuration changes and deployments that might be the root cause. The fix is to always check the audit log during incident investigation. The second pitfall is not logging all actions. If some actions are not logged (e.g., manual container restarts via SSH), the audit trail is incomplete, which makes investigation difficult. The fix is to ensure all state-changing actions are logged, including manual actions. The third pitfall is logging sensitive information. Audit logs can contain secrets (e.g., environment variable values), which should be redacted. The fix is to redact sensitive values (e.g., replace with [REDACTED]) before storing them. The fourth pitfall is not retaining logs long enough. If logs are deleted too quickly (e.g., after 30 days), you might not have the logs you need for a late-discovered incident. The fix is to set a long retention period (e.g., 1 year) or to export logs to an external system for long-term retention. The fifth pitfall is not securing the audit log. If the audit log is accessible to unauthorized users, they might tamper with it, which defeats the purpose. The fix is to make the audit log append-only (entries cannot be modified or deleted) and to restrict access to authorized users.
Conclusion: Track Every Action for Security and Compliance
Deployxa's audit log system tracks every state-changing action, providing a complete audit trail for security, compliance, and incident investigation. By recording who did what and when, the system ensures accountability and enables rapid incident response. For more on Deployxa's engineering, see our articles on the build cache architecture and the health check system. Learn about how we handle container restarts and how we handle custom domains in our companion articles. Explore our free developer tools to speed up your workflow. Try Deployxa Drop for an instant live preview with zero signup.