Your logs expire in 24 hours
A customer emails on Friday about a charge that went wrong on Tuesday. You open the platform dashboard and the request is not there any more. Xano's docs list 24 hours of retention for API requests, functions, middleware and triggers, with 7 days for background tasks. Bubble's logs tab searches server-side actions but the manual notes results are currently limited to the previous two weeks. Neither number is a scandal. Both are the reason you end up debugging from a customer's memory of what they clicked.
Retention is a line on the price list
Supabase is the useful comparison here because it prints the number instead of burying it. Log retention runs 1 day on Free, 7 days on Pro, 28 days on Team at $599 a month, and 90 days on Enterprise. Continuous export goes through Log Drains at $60 per drain per project per month, plus $0.20 per million events and $0.09 per GB of egress. Managed Postgres charges you for memory too. Anyone selling you a migration on the promise that logs become free is selling you something.
The difference shows up when the window turns out to be too small. With a drain you point the events at storage you already pay for and keep them as long as your support process needs. On a closed platform the window is the window, and the only lever is a plan upgrade that also hands you four features you did not ask for. Xano at least exposes the same records through its Metadata API, so you can pull them out on a schedule before they age off, which is a real escape hatch and worth using if you stay.
Think of the window as the age of the oldest bug you can still investigate. If your users report problems within a few hours, 24 hours is generous. If a billing error surfaces at the end of a monthly cycle, it is not.
The dashboard answers a different question than the one you have
Webflow Analyze, sold as a paid add-on, shows sessions, unique visitors, bounce rate, time on page and clickmaps, and lets you view up to 90 days at once. It is a good product. It will tell you that visitors left the pricing page. It will not tell you that a CMS collection query was the reason, because nothing in it looks at the server.
Xano documents something I wish more vendors did. The summary metrics on the request history dashboard, including success rate and p95 duration, are calculated from the requests currently loaded in the table rather than a server-side aggregate of all history. Click load more and the p95 changes. That is honest of them and it is also the whole problem: a latency percentile that depends on how far you scrolled is not a number you can put a threshold on.
Bubble's page load metrics come with a similar shape. The docs say the data is gathered over the latest page loads by all your users over the last 60 minutes. An hour-wide rolling window catches an incident happening right now. It cannot answer whether last Tuesday's change made checkout slower, which is the question you actually ask after a deploy.
What owning the logs buys, and what it costs
On Postgres, pg_stat_statements ships with the database and tracks calls, mean execution time and total execution time for every normalized statement. Set log_min_duration_statement and slow queries write themselves into the server log. Turn on pgAudit when you need statement classes for a compliance review. None of it is a tier. You can sort your own queries by total time spent and find the one eating the box, which is the single most useful half hour in performance work.
When we moved Stay World Class off Webflow and Xano to Next.js, NestJS and Supabase, the headline numbers were Lighthouse 55.91 to 91 out of 100 and LCP 77 percent faster, with a four stage ETL mapping legacy IDs onto PostgreSQL UUIDs. The part that mattered six months later was duller. We could see which queries were slow and rank them. On the old stack the timings existed, we just could not get at them in a form we could sort.
Then the bill arrives. Retention becomes your job: a drain, an S3 bucket, a Grafana or Datadog subscription, and a person who reads the output. Teams migrate, set up none of that, and end up with worse visibility than the dashboard they left. The capability is what you gain. The practice is still on you.
When the short window is the right answer
If you run a marketing site on Webflow, there is no backend to trace and Analyze is exactly the tool for the job. Buying an observability stack to watch a site with no server logic is spending money to feel professional.
If your volume is low and users tell you about problems the same day, 24 hours of history covers almost everything you will ever look at. The same goes if nobody on the team currently opens the logs. Owning your logs changes nothing for a team that does not read them, and a migration justified on observability alone is a migration justified on a habit you do not have yet. Build the habit inside the platform first. If you find yourself exporting request history on a cron to get around the window, that is the signal worth acting on.
