AI App Builder Audit Logs (2026): Four Different Promises

Quick Answer

Every builder here will tell you it has logs. None of them means the same thing by it.

"Audit log" is four separate promises wearing one name, and they are answered by four different systems that mostly do not talk to each other:

1. Who changed the app. Somebody edited a page, changed a schema, pushed to production.
2. Who changed the data. A row was created, updated or deleted.
3. Who signed in. An account authenticated, a session was issued, a token was revoked.
4. What your end users did. A customer of the app you shipped opened a screen, ran an action, exported a report.

In September 2026, exactly one of these eight products answers all four in one place, and it is not the one most people would guess. Most answer one or two. Several answer the first question with a version-history timeline that does not record a name, which is a rollback feature rather than an audit trail.

• 

  Base44 answers all four, on one Logs page, with a User column.

• 

  Webflow answers three, but splits them across two separate Enterprise logs that you query separately.

• 

  Lovable answers app changes and sign-ins thoroughly, and touches data.

• 

  Bubble is the only product here that names who made a change without charging Enterprise money for it.

• 

  Replit and

  

  v0 answer the builder-side questions properly and the app-side questions not at all.

• 

  Bolt.new publishes no audit log page in its documentation index.

• 

  Softr has a history feature that explicitly excludes user management from what it records.

And there is a fifth question nobody asks until the week they need it: how long does the answer survive, and can you take it with you? The published retention figures in this comparison run from fourteen days to never expires. That is the spread that actually decides whether a log is useful in an investigation, because investigations start when somebody notices, and people notice late.

The four questions are answered by four different systems

The reason "does it have audit logs" is a bad question is that the four promises live in genuinely different parts of these products, built by different teams at different times for different buyers.

Question one, who changed the app, is a developer-tooling concern. It grew out of version control, so in most of these products it is answered by a timeline of snapshots you can roll back to. That heritage matters, because a rollback timeline is optimised for restoring rather than for attributing, and several of them do not bother to record a name at all.

Question two, who changed the data, is a database concern, and it usually lives in whatever observability surface the underlying database exposes. It tends to be recorded as queries rather than as a business fact, which means it can technically be present and practically unreadable.

Question three, who signed in, is an identity concern, and in this category it is overwhelmingly a compliance feature. It shows up bundled with SSO and SCIM, sold on the Enterprise plan, and routed through the same vendor infrastructure that provides the rest of the identity stack.

Question four, what your end users did, is an application concern, and it is the one that is genuinely hardest to get for free, because the platform does not know what your app means. It knows a row changed. It does not know that the row was a refund.

That last distinction is why the answers cluster the way they do. Seven of these eight products can tell you something about your team. Two can tell you something about your users.

Axis 1: which of the four questions the log actually answers

The one product that answers all four

Base44 is the outlier, and it is worth being precise about why, because the shape is unusual.

It ships a single Logs page that is documented as covering "everything that happens in your app, from user actions and function calls to schema and integration changes". The runtime half records "entity operations (created, updated, deleted, restored), user events (registered, login, invited, role changed, page visits), access requests, function calls, integration and automation executions, agent conversations, data imports, file uploads, and security checks". The setup half records "app lifecycle events (created, published, unpublished), entity schema changes, payment and OAuth integration setup, and domain changes".

Read that list against the four questions. Entity operations is question two. User events covering registered and login is question three. Page visits is question four. App lifecycle and schema changes is question one. Every row carries a Type, User and Timestamp column, and you can filter to a single person by typing an email address.

On top of that there are two extras. An Enterprise-only Audit Logs API exists to "stream audit events into your SIEM or security tooling" and to "investigate user activity across all apps in a workspace". And the SDK exposes a method, logUserInApp(pageName), documented as recording "when a user visits a specific page or section of the app", with the useful note that "the specified page name doesn't have to be the name of an actual page in the app, it can be any string you want to use to track the activity". That is an escape hatch for the semantic problem above: the platform cannot know a row was a refund, but you can call logUserInApp('refund-issued') and make it know.

The honest caveat is that Base44 publishes no retention period for the Logs page and no bulk export from it, beyond a copy icon on an expanded row. So it answers all four questions and does not tell you for how long.

Two logs that answer three questions, in two places

Webflow's answer is complete on paper and awkward in practice, because it is two products.

The Workspace audit log API covers identity only, and its documented event types are exactly six: user_access ("Login and logout events for users in the workspace"), custom_role, workspace_membership, site_membership, workspace_invitation and workspace_setting. That is question three, plus the access-control half of question one, and nothing else. No design change, no CMS row, no deployment appears in it.

The Site Activity log covers the rest. Its API reference states plainly that "this endpoint requires an Enterprise workspace", and the events it returns cover page modifications, publishing, CMS operations, custom code changes and collaboration activity such as branch merges. Each entry carries a user object with an id and a display name, plus newValue, previousValue, resourceName and an actorType. A before-and-after pair on a named user is as close to a real audit record as this category gets.

So Webflow answers questions one, two and three well, and answers question four not at all, because the app-side user model was removed in January 2026. If you want to know what a signed-in customer did inside a Webflow site in 2026, there is no customer.

The builder-side specialists

Replit's audit log is a serious compliance product aimed squarely at questions one and three. It is documented as capturing "more than 50 event types" across deployments, access and identity, workspace administration, project activity, secrets, connectors, domains and, interestingly, agent activity. In a product where an AI agent makes changes on your behalf, logging what the agent did is the right instinct and most of this field has not had it yet.

What it does not do is question two or question four. There is no documented data-change log and no app-side user activity.

v0 inherits Vercel's audit log, and it has the richest actor metadata in this comparison by some distance. The exported CSV carries timestamp, action, actor_vercel_id, actor_name, actor_email, location ("IP address from where the action was performed"), user_agent, request_id, and both previous and next as JSON snapshots of the object's state.

The action list is long and is entirely about the team and its projects: aliases, certificates, domains, deployments, integrations, environment variables, project transfers, SSO protection, rolling releases, team membership. One entry is worth singling out because almost nothing else in this category records it: shared_env_variable.decrypted, which fires when somebody reveals a shared secret. That is a genuinely good event to have.

But it is a team log, not an app log. There is no data-change event, no app-side user, and notably no login event for the team either. It tells you what your colleagues did, not when they arrived.

The ones that record the change without recording the person

Softr's App History is documented as "a timeline of the changes that have been made to your app throughout its existence". That sounds like question one, and it is not, for two reasons.

The first is that the documentation never identifies who made a change. It is a snapshot list you restore from, not a record you investigate with.

The second is sharper, and it is the single most quotable line in this whole comparison. The documentation lists what App History will not capture: "Page name or path change; App name change; Domain or subdomain setup; Adding, editing, or deleting users." The one category of change that an audit log exists to cover, user management, is explicitly named as the thing this history does not record.

For question three, Softr surfaces a last login date on the user record and nothing further. A community feature request asking to see "all my users login activity" rather than "just the most recent one" was posted in January 2023 and was still attracting interest in March 2024 with no visible product commitment.

Bolt.new is the plainest case here. Its published documentation index lists ninety-four pages and not one of them is an audit log. What it has instead is "Backups, restore, and version history", described as restoring "a previous point in your project and manage backups using version history in the chat", and a "Database: Logs" page covering "events, queries, and system messages that help you understand how your data is being accessed or changed".

The database logs are real and they are the answer to question two, with a caveat: the documentation does not state whether an entry identifies the user who performed the action, and does not state a retention period. Version history in the chat is a rollback timeline attached to a conversation, which makes it a personal undo rather than a team record.

This is an absence in the documentation rather than a proven absence in the product. It is worth stating that distinction rather than blurring it: what is established is that Bolt.new does not publish an audit log page, not that no log exists anywhere in the product.

The two that sit in the middle

Lovable's audit log is Enterprise-only and visible to workspace owners and admins. Its documented categories are workspace membership, workspace management, workspace groups, identity and access, secrets and integrations, projects, Lovable Cloud and authentication.

Two of those are more interesting than they look. Under projects, the list includes "database queries" and "prompts", which means Lovable is logging both what was asked of the AI and what it went on to run against your data. Under Lovable Cloud, the list includes "auth settings, cloud users, storage buckets", which is the closest anything in this comparison gets to question four without being Base44.

It is still fundamentally a workspace log. It will tell you that a query ran; it is not documented as telling you which rows changed.

Bubble does the least fashionable thing and the most useful one. Its changelog records, in the documentation's own three-sentence summary, "Who made the change. When it happened. What changed." You can filter the changes by who made them through a Collaborators dropdown, and it covers workflows, visual elements and settings.

Crucially, this is available on any paid plan. It is the only product in this comparison that answers "who changed the app" by name without an Enterprise contract.

Its server logs cover the app-side half: server-side actions such as sending email or changing data, searchable by time range, by the email address of the user who initiated the event, and by a freetext workflow label. That is a partial answer to questions two and four at once, expressed in the vocabulary of workflows rather than of business events.

Axis 2: how long the answer survives

This is where the comparison stops being about features and starts being about whether the log is any use.

Investigations do not begin the moment something happens. Somebody notices a discrepancy in a monthly reconciliation, or a customer complains about a change nobody remembers making, or a departing employee's access is reviewed a few weeks after they leave. A fourteen-day window does not cover a monthly cycle. A thirty-day window barely does.

The published figures, in order:

• Webflow Site Activity log: does not expire. The longest-lived record here by a wide margin.
• Bubble changelog: 14 days on Growth, 20 days on Team and Agency, 30 days on standard Enterprise, one year on dedicated Enterprise. This is the only real retention ladder in the category, and it is the only place where paying more buys you memory rather than features.
• Lovable: 13 weeks, roughly 90 days, with events older than that removed automatically.
• Replit: 30 days by default. Longer retention is not a plan upgrade, it is an architecture decision: you set up SIEM streaming and keep the logs in your own storage.
• Bubble server logs: the previous two weeks. Note that this is a different and much shorter window than the same product's changelog, which is exactly the kind of split that catches people out.
• v0, Base44, Bolt.new, Softr App History: not published. Vercel's documentation states that audit log reports "generated for the last 90 days (three months) will not impact your billing", which strongly implies that older exports are possible and may cost, but it is not a retention statement and should not be read as one.

The pattern worth noticing is that the two products with the most sophisticated audit tooling, Replit and v0, both effectively answer the retention question with "stream it somewhere else". That is the correct enterprise answer and it is also a real cost: it means the log is only as durable as the SIEM pipeline you have not built yet.

Axis 3: whether you can take the log with you

A log you cannot export is a log you can only read inside the vendor's interface, which means it stops existing the day you leave. Since the whole point of this comparison series is what happens when you change your mind, this axis matters more here than it would elsewhere.

• v0 exports CSV. You pick a timeframe, the team owner receives an email with a link, and the link is valid for 24 hours. It also supports SIEM streaming to S3, Splunk, Datadog, Google Cloud Storage or any HTTP endpoint, though the documentation now carries a warning that Custom SIEM Log Streaming is being replaced by Audit Log Drains.
• Lovable exports JSONL, packaged as audit_logs.jsonl.zip, matching whatever filters are active. Finished exports stay available for seven days.
• Replit supports bulk export downloads from the audit portal, plus streaming to Datadog, Splunk, Amazon S3 or a generic HTTP endpoint.
• Webflow exposes both logs as API endpoints, paginated at a maximum of 100 records per request, which is an export in the sense that developers mean it and not in the sense that a compliance officer means it.
• Base44 offers an Enterprise Audit Logs API for streaming, and for the Logs page itself documents only a copy icon on an expanded row.
• Bubble, Bolt.new and Softr do not document an export for any of the log surfaces discussed here.

There is a neat detail in the v0 action list that shows what a mature version of this looks like: auditlog.export.requested and auditlog.export.downloaded are themselves logged events. The audit log audits access to the audit log. Almost nothing else in this category does that, and it is the difference between a log built for engineers and a log built for auditors.

The comparison table

Scored on the four promises, September 2026. "Documented" means the vendor's own documentation says so; a blank is an absence in the documentation rather than a proven absence in the product.

The details that decide whether it works at all

Who is allowed to read the log is part of the feature. Replit states that "only account admins can access audit logs and configure SIEM integration" and that "non-admin members do not have access to any audit log data". Vercel restricts audit logs to the owner role. Lovable limits them to workspace owners and admins. This is not a footnote: if the person who investigates incidents at your company is not the person who owns the billing account, the log is behind a door they cannot open. That interacts directly with how each product models team roles versus app roles, and the two systems are not always the same one.

Enabling the log can cost you something structural. Replit's documentation carries a limitation that deserves more attention than its placement suggests: audit logs are supported for single-workspace accounts only, and "enabling audit logs will disable additional workspace creation for your organization". Turning on compliance tooling permanently changes how you are allowed to organise your work. That is an unusual trade and it is easy to miss.

The log may start when the feature does, not when your app did. Several of these products added audit logging well after launch, and a log cannot retroactively record events from before it existed. If you are choosing a builder because of an audit requirement, the question is not only whether the feature exists but whether it was switched on before the period you will be asked about.

Prompts and queries in a log are a data-protection surface of their own. Replit's documentation warns that prompt text captured through its Compliance API "can contain secrets, personal data, and other sensitive content". Lovable logs prompts and database queries too. That is the right thing to record and it means your audit log is now a system that holds sensitive data and needs its own access controls, retention policy and deletion story. A log is not automatically a safe place to put things.

In a regulated setting, the audit trail is a gate rather than a nice-to-have. If you are choosing a tool where an auditor will eventually ask who accessed a record, the four promises stop being a feature comparison and become a shortlist filter, and it is worth reading this alongside the criteria that matter in a regulated vertical like a clinic, where access records are usually the first thing anyone asks for.

Two logs is not the same as one log. Webflow's split is the clearest example. To reconstruct "a contractor was added to the site and then changed the pricing page", you must query the Workspace audit log for the membership event and the Site Activity log for the design change, then correlate them by timestamp yourself. Nothing joins them for you. That is entirely workable, and it is a different amount of work from reading one page.

Verdict, September 2026

If you need all four answers in one place, Base44 is the only product here that gives them to you, and the Logs page is not gated behind an Enterprise contract the way almost every competitor's audit surface is. The thing to check before committing is retention, because it is not published, and a log with an unknown lifespan is hard to build a compliance story on.

If you need the longest memory, Webflow's Site Activity log does not expire, which no other product in this comparison claims. The cost is that you need Enterprise, you need to query two separate logs, and there is no end-user layer left to audit.

If you need a named actor on a small budget, Bubble is the answer and it is not close. Fourteen days is short, but "who made the change, when it happened, what changed" on any paid plan is more than seven of these eight products will tell you at any price.

If you are an enterprise with a SIEM already running, Replit and v0 are both built for you and are the two best citizens here on export and streaming. v0 has the better actor metadata, including IP address, user agent and before-and-after state. Replit has far broader event coverage and is the only one logging what the AI agent did. Neither will tell you anything about the users of the app you shipped.

If the audit requirement is real and specific, be careful with Softr and Bolt.new. Softr's history explicitly excludes user management, which is usually the first thing anyone asks about, and Bolt.new publishes no audit log documentation at all.

The broader point is the one at the top. In this category "we have audit logs" is not a claim you can evaluate. Ask which of the four questions it answers, ask how long the answer lasts, and ask whether you can take it with you. Most of the time at least one of those three answers is missing, and it is almost never the one the marketing page is talking about.