Caching and data freshness
RentalTide caches certain types of data in your browser to keep pages fast and to avoid repeatedly hitting our servers for information that rarely changes. Most caches use a 5-minute window. If you make a change in one tab and do not see it reflected in another tab right away, the cache is almost always the reason.
This page explains what is cached, why, and how to force a refresh when you need the very latest data.
Why we cache
Every page in RentalTide reads from many sources at once: bookings, inventory, location settings, pricing rules, customer records, staff lists, tax rates, and more. Loading all of that fresh from the database on every page navigation would make the app feel slow and put unnecessary load on the platform.
Caching solves three problems at once:
- Page loads stay fast. Navigating between bookings, calendar, and the journey board feels instant because shared data is already in memory.
- Server load stays low. A typical operations day involves thousands of page loads per location. Without caching, every one would re-query the database for the same settings.
- Bandwidth is reduced. This matters most for staff on mobile devices or slow Wi-Fi at the dock.
The tradeoff is a short delay between making a change in the admin panel and seeing it reflected on customer-facing pages or other staff devices. We chose 5 minutes as the default because it is short enough that operational mistakes self-correct quickly, but long enough that the performance benefit is real.
What is cached
The list below covers the data that is most commonly cached in the browser. This is not exhaustive — many pages use short-lived (under 30 second) caches for live data like the journey board and rundown.
5-minute cache (most common)
| Data | Where it shows up |
|---|---|
| Pricing | Booking widget, walk-up flow, POS register, checkout |
| Inventory settings | Fleet pages, availability checks, asset detail panels |
| Location settings | Tax rates, operating hours, fees, deposit rules |
| Customer settings | Admin settings page, staff permissions, terminal configuration |
| Analytics dashboards | All eight analytics tabs |
| Year-over-year revenue | Operations homepage revenue comparison |
| Today's hub | Daily ops page (today's rentals and tour sessions) |
Longer-lived caches
| Data | Cache duration | Why it's longer |
|---|---|---|
| Stripe Capital eligibility | 24 hours | Computed from 84 days of charge history; expensive to recompute |
| Access tokens | Until token expiry | Auth tokens refresh proactively 5 minutes before they expire |
| Logos, photos, attachments | Browser default (often hours) | Static files served from our CDN with long cache headers |
Short-lived caches (under 1 minute)
Some live data uses very short caches that you will rarely notice — pricing calculations dedupe within 500ms, slip waitlist data refreshes every 30 seconds, etc. These exist mainly to prevent the same network request from firing multiple times when several components on the same page need the same data.
What is not cached
The following data is always fresh and reflects the database immediately:
- Booking creation and payment. When a customer books or pays, the record is written to the database in the same request. No staff member will ever see a booking go missing because of a cache.
- POS transactions. Every sale, refund, and till adjustment is recorded immediately.
- Ledger entries and accounting. Financial state is always read from the source of truth.
- Walk-up state and timing. The "left" and "back" timestamps update in real time.
- Calendar and journey board status. These poll for changes frequently so other staff devices see updates within seconds.
When the cache will surprise you
The most common moments where the cache becomes visible:
- You changed pricing on an inventory item and the booking widget still shows the old price. Wait up to 5 minutes, or have the customer hard-refresh the page.
- You updated tax rates in store settings and walk-up still applies the old rate. Refresh the walk-up tab, or wait 5 minutes.
- You added a new staff member and they don't appear in the schedule dropdown on another device. Have the other device refresh.
- You created a new promo code and a test booking won't accept it. Promo codes propagate immediately for new bookings but cached pricing tables on already-open tabs may take up to 5 minutes to refresh.
If you are unsure whether you are seeing a cache issue or a real bug, force a refresh first (see below). If the problem persists after a forced refresh, it is not a cache issue.
How to force a refresh
You have several options, from least to most disruptive:
1. Use the page's refresh button
Many pages — analytics, reporting, the journey board, and the home dashboard — have a refresh icon in the page header. Clicking it bypasses the cache and fetches the latest data for that page only.
2. Navigate away and back
Closing a page and reopening it from the sidebar will typically refresh its data. This works because most caches are tied to component mounts.
3. Hard-refresh the browser
A hard refresh clears the in-memory cache for the current tab and forces all data to reload from the server.
- Mac:
Cmd + Shift + R - Windows / Linux:
Ctrl + Shift + R - iOS / Android: Pull down to refresh, or close and reopen the tab
4. Log out and back in
This is the most thorough option. It clears the access token cache as well as the data caches, and is appropriate if you suspect a permissions issue is being cached.
If a customer reports seeing old pricing or stale availability on your booking widget, ask them to hard-refresh their browser. The widget caches data on their device the same way the admin app does on yours.
Frequently asked
Will my customers see stale pricing for 5 minutes after I change a price?
Possibly, if they had your booking page open when you made the change. New visitors will see the new price immediately. Existing visitors will see it within 5 minutes, or sooner if they navigate or refresh.
Does caching affect payment processing?
No. Payment processing always uses live pricing computed on the server at the moment of payment. A cached price shown on the booking page is only ever a display value — the final charge is recalculated server-side before any money moves.
Can I disable caching for my location?
Not currently. The cache is a platform-wide design choice and turning it off would significantly slow down the app for everyone using your location. If you have a use case where 5 minutes is too long, contact support and we can discuss the specifics.
My change still hasn't appeared after 10 minutes. What now?
This is not a cache issue. Check the audit log for the relevant page to confirm the change was saved, and reach out to support if needed.
Summary
- Most data is cached in your browser for 5 minutes to keep page loads fast.
- Bookings, payments, and POS transactions are never cached — they are always live.
- To force fresh data: click a page's refresh button, navigate away and back, or hard-refresh the browser.
- Final charges are always recalculated server-side, so cached pricing on a display page cannot cause an incorrect charge.