Skip to main content

Overview

The CrewAI Platform records an audit trail of changes to Crew deployments in the versions table. Each row captures:
  • item_type — the audited model, which is Deployment for Crew deployments.
  • event — one of create, update, or destroy.
  • whodunnit — the ID of the user who made the change. Join against the users table to resolve the actor’s email.
  • created_at — when the change occurred.
  • object — the serialized state of the Crew deployment before the change (JSON).
  • object_changes — the changed attributes, as a JSON map of attribute → [old_value, new_value].
Run these queries against the platform’s primary PostgreSQL database. See Troubleshooting for instructions on opening a psql session against the in-cluster database.
All audit rows for Crew deployments use item_type = 'Deployment'. The queries below all filter on that value, then narrow further by event and — for deploy/redeploy activity — by the contents of object_changes.

Created Crews

List every Crew deployment that has been created, ordered by most recent first. The joined email column identifies the user who created the Crew.
SELECT v.*, u.email
FROM versions v
LEFT JOIN users u ON u.id::text = v.whodunnit
WHERE v.item_type = 'Deployment'
  AND v.event = 'create'
ORDER BY v.created_at DESC;

Updated Crews

List every update applied to a Crew deployment. This covers all attribute changes — for example, configuration edits, environment variable updates, permission changes, and the status transitions that occur during a deploy or redeploy.
SELECT v.*, u.email
FROM versions v
LEFT JOIN users u ON u.id::text = v.whodunnit
WHERE v.item_type = 'Deployment'
  AND v.event = 'update'
ORDER BY v.created_at DESC;
To exclude the noisy status-transition rows that the platform writes during a deploy and see only direct configuration edits, filter out updates that only touch current_status and its companions:
SELECT v.*, u.email
FROM versions v
LEFT JOIN users u ON u.id::text = v.whodunnit
WHERE v.item_type = 'Deployment'
  AND v.event = 'update'
  AND NOT (v.object_changes ?| array['current_status', 'progress', 'error', 'full_error'])
ORDER BY v.created_at DESC;

Deployed / Redeployed Crews

A deploy or redeploy is recorded as an update row whose object_changes shows current_status transitioning to "Deploy Enqueued". The query below lists every such transition.
SELECT v.*, u.email
FROM versions v
LEFT JOIN users u ON u.id::text = v.whodunnit
WHERE v.item_type = 'Deployment'
  AND v.event = 'update'
  AND v.object_changes -> 'current_status' ->> 1 = 'Deploy Enqueued'
ORDER BY v.created_at DESC;
To distinguish a first-time deploy from a redeploy, rank the transitions per Crew deployment in chronological order — the first row for a given item_id is the initial deploy, every subsequent row is a redeploy:
SELECT
  v.*,
  u.email,
  CASE
    WHEN ROW_NUMBER() OVER (PARTITION BY v.item_id ORDER BY v.created_at) = 1
    THEN 'deploy'
    ELSE 'redeploy'
  END AS deploy_kind
FROM versions v
LEFT JOIN users u ON u.id::text = v.whodunnit
WHERE v.item_type = 'Deployment'
  AND v.event = 'update'
  AND v.object_changes -> 'current_status' ->> 1 = 'Deploy Enqueued'
ORDER BY v.created_at DESC;
Each deploy or redeploy also produces a new row in the deployment_instances table, scoped to the parent deployment via deployment_id. Counting those rows per deployment_id is an equivalent way to track deploy frequency without inspecting object_changes.

Deleted Crews

List every Crew deployment that has been deleted, ordered by most recent first. The joined email column identifies the user who performed the deletion, and the object column contains the full state of the Crew at the time of deletion.
SELECT v.*, u.email
FROM versions v
LEFT JOIN users u ON u.id::text = v.whodunnit
WHERE v.item_type = 'Deployment'
  AND v.event = 'destroy'
ORDER BY v.created_at DESC;
The object and object_changes columns on each versions row contain the serialized before/after state of the Crew deployment. Use object to reconstruct the attributes a Crew had at the time of the event, and object_changes to see exactly which fields moved and what their old and new values were.