Budibase 4.0: Audit Your AI Agents with the New Activity Log
Letting an AI agent handle requests and approvals is the easy part. The hard part comes a week later, when someone asks why a refund went through, or why a ticket sat untouched for two days, and all you have is "the agent did it."
Budibase 4.0, released on November 10, 2026, goes after that problem. The headline change in the release is an Activity view that records what your agents and automations actually did, step by step, including every tool call. Here's what it gives you, how it behaves on a self-hosted install, and what to check before upgrading.
What the Activity View Records
Budibase 4.0 adds two tabs under Activity: Requests and Actions. Actions is the interesting one. It lists two kinds of sessions side by side:
- Agent sessions: each run of one of your AI agents.
- Automation runs: each execution of a Budibase automation, including automation steps that call agents.
Every session shows a status, a count of actions and when it was last updated. The status is one of four:
| Status | What it means |
|---|---|
| Active | Still running |
| Waiting | Paused, waiting on something before it can continue |
| Completed | Finished normally |
| Failed | Stopped on an error |
Open a session and you get a timeline of its events, with readable labels and failure details. The part that matters most for agents: tool calls are recorded, both successful and failed ones. So when an agent looked up a customer, checked an order and then updated a record, you can see each of those steps in order, not just the final answer.
You can filter by status and by environment (development or production), and summary cards at the top count sessions per environment.
Why This Matters More Than It Sounds
Most agent setups give you either nothing or a raw log file. Neither helps when a manager asks what happened to a specific request. An activity trail that a non-developer can open in the same tool they built the agent in is the difference between "trust me" and "here's what it did."
It also helps while you're building. A session stuck on Waiting tells you something is holding it up. A Failed session with a tool error tells you which integration broke, without trawling logs.
Reading It From Code
The same history is available through two workspace-scoped API endpoints, added in pull request #19795:
| Endpoint | Returns |
|---|---|
GET /api/actions/sessions | Sessions with summary counts, filterable by env and status |
GET /api/actions/sessions/:sourceType/:sourceId/events | The event timeline for one session (requires env) |
sourceType is either agent_session or automation_run, and both endpoints page through results with a bookmark and limit. Requests pick the workspace with the x-budibase-app-id header, and only builders and admins can call them. That's useful if you want to push agent activity into your own dashboards or alerting.
How It Behaves on a Self-Hosted Install
Two things self-hosters should know, both from the release's pull requests.
It's on by default. Self-hosted Budibase doesn't evaluate the feature flags that the cloud version uses, so earlier builds left new features switched off. 4.0 changes the defaults: agent tests, request tracking with its requests portal, and the Actions tab are now enabled automatically on self-hosted installs, and so are Projects. You can still switch individual features off with the TENANT_FEATURE_FLAGS environment variable. For example, the Projects pull request uses TENANT_FEATURE_FLAGS=*:!PROJECTS to disable Projects.
History doesn't last forever. Completed and failed sessions are cleaned up after a retention period that comes from your licence's platformActionsRetentionDays quota. The release doesn't say what that value is on a free self-hosted install, so check how far back your Activity view goes before you rely on it for audits. If you need a permanent record, copy sessions out through the API on a schedule.
Also in 4.0
- Portable project agents. Exported agents no longer carry references to the source workspace's AI settings. After import, they stay switched off until you give them an AI configuration, plus any Slack or Microsoft Teams setup they need.
- A security fix for CVE-2026-111497, the Brotli flaw that landed on CISA's exploited list last month, in the Node runtime of the apps and worker services.
Upgrading
This is a major version, so back up before you start. Budibase stores its data in CouchDB and an object store, alongside a Redis cache, so back up the volumes your docker-compose.yml defines.
For the official Docker Compose setup, update the image tags, then pull and restart:
docker compose pull
docker compose up -d
docker compose logs -f app-service worker-service
The service names above come from Budibase's own compose file. Replace them if yours are different.
On Elestio, Budibase starts at $11/month for the VM. Rehearse on a copy with the Clone button in your dashboard, or let Elestio AI DevOps run the upgrade. It takes a backup before it touches anything.
Troubleshooting
The Actions tab doesn't appear. Check TENANT_FEATURE_FLAGS in your environment. An old override may still be switching PLATFORM_ACTIONS or AI_AGENT_ACTIVITY off.
A session sits on Waiting. Something is holding it up. Open the session timeline to see the last event before it paused, and check Requests for anything pending.
The summary cards show "unavailable" instead of numbers. The Activity view couldn't load its counters, and it says so rather than showing a misleading zero. Reload, and check the app service logs if it keeps happening.
Older sessions disappeared. That's the retention cleanup. Export what you need through the API before it ages out.
An imported agent won't run. Imported agents stay off until you assign an AI configuration and finish any Slack or Teams setup.
Thanks for reading ❤️ See you in the next one 👋