Lovable now saves your form submissions and watches your live app for errors. Here's what to switch on

Lovable shipped a batch of updates between October 30 and November 4. Several of them help with problems founders hit once an app is live. Forms that Lovable builds now save every submission to a database table. Paid plans can watch for errors in your visitors' browsers and email the project owner when something important breaks. Lovable also remembers what you tell it across chats, and on paid plans it tidies that memory in the background.

The details are spread across a week of changelog entries. If you've ever lost leads from a contact form, or found out a payment page was broken from an annoyed customer, these are the changes worth checking this week. The memory cleanup uses no credits. Monitoring uses credits on each run, and its visitor error checks only work if you turn on a setting called Visitor analytics.

Form submissions now land in a table

As of November 3, when you ask Lovable for a contact, booking or quote form, it saves each submission to a table and tells you the table's name in the chat. You can also have each submission emailed to you. Those emails go out from a verified sender domain, which needs a paid plan.

The table gives you a record of every submission that you can browse, filter and export as CSV from the Database view.

The changelog describes forms Lovable builds, so it's unclear whether forms made before November 3 changed. If you have older forms, submit a test entry and check the Database view. If nothing shows up, ask Lovable to save that form's submissions to a table.

Monitoring now checks what your visitors see

Project monitoring is in beta on Pro, Business and Enterprise workspaces. It already scanned your code for broken logic and UI. From November 2 it also checks errors in visitors' browsers, alongside recent server-side errors, and traces them back to likely causes in your code. Lovable's examples include sign-in errors, failing payments, unsaved inputs and broken integrations.

The project owner gets an email for important or time-sensitive findings. Editors see a summary above the chat.

There are two catches. Browser errors are only collected for published apps with Visitor analytics turned on in project settings. And monitoring is set per project, so you need to switch it on for each app.

Set the schedule for apps you rarely touch

By default, checks run daily at 6:00 in your timezone, but only if someone edited the project since the last check. That works for code checks. It's less useful for a live app you finished months ago, because visitor errors in an app nobody edits won't get checked under the default.

In Project settings → General → Project monitoring you can switch to weekly checks, change the time, and choose whether checks run every time or only after a minimum number of edits. For a live app that earns money or collects leads, set it to run every time.

What monitoring costs

Each completed scheduled run uses credits, and the cost shows up in the monitoring history. Your included daily credit grants are used first. Checks that are skipped, because the edit threshold wasn't met or the workspace is out of credits, use nothing.

Lovable doesn't publish a per-run price, so check the history after the first few runs before you turn it on across every project. Weekly checks are a sensible starting point for apps with low traffic.

Monitoring doesn't replace testing. It can miss issues, especially when a scan finds many, it can flag working behavior as broken, and it doesn't fix anything itself. Treat findings as leads to check, and ignore the false positives.

Lovable now remembers your decisions

Since October 30, Lovable keeps two kinds of memory. Project memory holds preferences, ruled-out approaches, design choices and business facts, and everyone who can edit the project shares it. Personal memory holds how you like to work, such as reply length, and follows you across projects. It's visible only to you.

Technical decisions go into AGENTS.md files as short rules with a one-line reason. Since November 3, Lovable also reads AGENTS.md and CLAUDE.md files in the folder of any file it opens or edits, and in every folder above it. That lets you keep separate rules for, say, your admin area and your public pages.

One thing to watch: anyone who can edit a project can read its memory. Lovable strips known secret formats such as API keys, but other confidential text may slip through, so keep it out of your messages. If you share projects with clients or contractors, check the project's memory setting, where you can pick "You and this project," "Just this project" or "Nothing." Changing this setting doesn't delete what's already saved. To remove something, ask Lovable in chat to forget it.

Dreaming keeps that memory current

Over time, saved rules can stop matching your code. On paid plans, a feature Lovable calls Dreaming (from November 4) checks project memory and AGENTS.md against your code and chat, then updates or removes stale and duplicate entries. It uses no credits and never touches your app code.

Rules you asked for stay, even if the code doesn't match them yet. Lovable flags the mismatch later. Edits show up in chat and version history as "Lovable tidied up its notes," and "View code changes" shows what changed.

Settings don't show what Dreaming removed, so to bring something back you ask in chat or edit the file. Dreaming doesn't run in Git-sync projects, workspaces using EU inference, or projects with memory set to "Nothing." It checks a few items at a time, so a large project needs several passes.

One more for client work

If you build for clients who ask security questions, you can now download a software bill of materials from the Security view. It lists production dependencies and known vulnerabilities in SPDX 2.3 or CycloneDX 1.5 format, and it's free. It doesn't include license information.

What to do this week

• Submit a test entry on every live form and confirm it appears in the Database view. Set up email alerts if you're on a paid plan.
• On your most important live app, turn on Visitor analytics, then turn on project monitoring and set it to run every time.
• Check the credit cost in the monitoring history after a few runs before you add more projects.
• Check the memory setting on any project shared with clients.
• If you work on a large project, move rules for one area into an AGENTS.md file in that area's folder.