Built before you open it. Live the moment you do.
Your dashboard is a static page on your own hostname, served from the edge nearest you behind a login gate. Open it and last night's numbers render at once; the live ones arrive a moment later from a managed cloud service, and a stamp in the header says when they were pulled.
Will my dashboard load fast and stay up?
Yes, because the page is already built. Your dashboard is a static site on Cloudflare Pages at your own hostname, served from the edge location nearest the person opening it. No server renders it on request. An access gate on that hostname authenticates the visitor before a byte is served, and our seat list then confirms the person holds a seat on your account. Preview hostnames redirect to your canonical host with a 302, so a preview address cannot walk around the gate.
The page then asks a small function on the same edge for your live numbers. That function holds the secret needed to reach our service, so your browser never does. It sits behind the gate, so it only ever answers a request that already passed it.
Static at the edge has two effects you will notice. The page opens in the time a static file takes to arrive, and it stays up when a server somewhere is not, because no server sits in the path that renders it.
What will I see, and how soon?
Last night's numbers, in the first instant. The snapshot baked at 12:01am Central ships with the page and renders before any network call returns. The page then fetches your live payload through the edge function, and a warm service answers from cache in well under 200 milliseconds. Only after that payload lands does the page load its configuration and the engine, so every number it computes comes from the fresh data.
If the snapshot is older than five minutes, our service starts one pull of your connected sources behind the request. It holds the page for up to 1.5 seconds so that a quick pull, or one already nearly done because a colleague opened the dashboard a moment earlier, lands on the first paint. Anything slower arrives as one automatic reload that keeps your place on the screen, and the page reloads at most once per snapshot, so a pull that keeps failing can never put you in a loop. If the live fetch takes longer than four seconds, or fails, the snapshot stands and nobody waits.
Take 9am on a Monday. Ten people on your team open the dashboard within a minute. The first load starts one pull. The other nine do not start their own: they are served the current snapshot and pick up the fresh numbers when that one pull lands. Every one of them sees a stamp in the header that reads data, then the time of the pull. Hover it and it says either that the data was pulled live when the page opened, or that the live refresh was unreachable and this is the last saved snapshot. Staleness is never invisible.
The Refresh button forces a real pull of every connected source. A full pull takes two seconds to a little over three minutes depending on how many sources you have, so the button starts the pull, returns at once, and the page checks back until the pulled-at stamp moves, then reloads. Every path through it ends in a reloaded page, never in an error message.
Will my numbers keep coming if your machines are off?
Yes. The payload your page renders is served from a managed cloud service, not from a computer in an office. Our own machines pull from your connected accounts and push each snapshot up; they are not in the request path when you open the page. The service is read only by design: it holds no Google credentials and cannot run a pull. A real pull, the kind the Refresh button asks for, runs on our machines against your own sources, and the service keeps serving the last snapshot while it runs.
Which service answers is a setting on your project, not a code change. Moving a client between services is one variable and a redeploy of about a minute, in either direction. The edge function waits two seconds on the managed service before it falls back to our own machine, and if the shared secret is missing altogether the page renders the baked snapshot. A misconfigured project degrades to last night's numbers, never to a blank page.
Every step in that chain falls back to something older. None of it falls back to nothing.
Do I get every improvement, or do I fall behind?
You get every one, and a check enforces it. The engine, the styles and the boot loader are shared files, and the canonical copy is the one most instances agree on, so no single instance can quietly become the source. Improve the engine once and every client runs the improvement on its next deploy.
A preflight runs before every deploy, and the nightly bake runs the same gate. It checks that each instance's engine, styles and boot loader match the canonical copy, that every script parses, that every asset carries a version stamp, and that every view renders clean against that client's configuration. It refuses to ship an instance that has no access redirect, whose redirect is a cacheable 301 rather than a 302, whose scripts do not parse, or that carries another client's name anywhere in its files. Each of those checks exists because the failure it prevents happened once.
An engine change is proven against every client before any of them sees it. A render matrix loads each instance the way a browser does, renders every view its own menu exposes, and fails on a view that throws, renders empty or prints undefined.
Check it on the demo. demo.trulata.com runs the same engine file every client runs, on a fictional company with illustrative numbers and no form in front of it. Look for the data stamp in the header, click a headline card on the Overview and read its current value, change and window, then open the Team view to see seats used of plan seats. What the demo cannot show is your data. That arrives in week two of setup, when the first pull runs on your accounts; setup takes two to four weeks in all.
Will I ever open a blank page?
No. Every night at 12:01am Central one job rebuilds a static snapshot for every client from one registry and ships it with the page. That snapshot renders in the first instant of every load, and it is what you keep reading if the live service cannot be reached.
The job does five things in order for each client: run the pull, syntax-check every script, bump the version stamp on every asset so browsers and the edge fetch the new files, deploy through the one guarded path, and purge the edge cache for the page and every pinned asset. A failed pull or a script that fails its check stops the job before the deploy, and the previous night's page stays up. Inside an otherwise good pull, a source that fails keeps its previous value for that section, so a section is never shipped empty. A pull that hangs is cut off after a bounded time, so one client's bad night cannot take the others with it.
The door follows the same rule. If our seat service is unreachable, a person who has already passed the access gate stays in, and that decision is logged so the gap is visible rather than silent. The two refusals that never relax are a login minted for a different dashboard and a login with no email identity. Revoking a seat takes effect within 30 seconds.
What can it touch, and what can it not see?
It reads, through access you grant. Every Google connection is a manager invitation on your Analytics property, your Search Console site, your Ads account and your Business Profile listing, and you can revoke each one in your own console. We hold no passwords of yours. Your CRM, Stripe, your booking platform, your email platform and your website forms are connected by our team from the inside during setup; there is no wizard and nothing for you to paste.
Which of your accounts the dashboard may read is decided by a per-client map on our side, never by an id from the browser and never by one written into code. A view appears only when its source is connected, so Jobs shows only where your CRM or booking platform is linked. Dates you choose in the analytics view are checked before they reach Google, because they are browser input arriving through the edge function.
Four things on the screen write anywhere, and that is the complete list: ask a question in the assistant view where it is offered, set a lead outcome on your own lead record, request a website change, and request a content, keyword, category or targeting change. The requests go to your team and are logged. Nothing on the screen writes to your ad account, your CRM, your site or your Business Profile.
Three things are not connected on any client instance: your email inbox, your calendar and customer card data. Nothing records phone calls, so a phone lead counts only if your CRM records it. Freshness is bounded by each source: your CRM, Stripe, your booking platform, website leads and email statistics are live; Google Ads and GA4 intraday figures lag by hours; Search Console runs two to three days behind. The stamp in the header says when the last pull ran.
The stack, in one table.
| What | Where it comes from | How fresh |
|---|---|---|
| Dashboard | Static site on Cloudflare Pages, your hostname | Edge-served, already built |
| Gate | Cloudflare Access, then our seat list | Every request; a revoked seat is out within 30 seconds |
| Live data | Managed cloud service holding your snapshot | From cache in under 200 ms; re-pulled past 5 minutes |
| Pulls | Our machines, from your connected accounts | On open past 5 minutes, on Refresh, and nightly |
| Engine | Shared files, preflight before every deploy | The same file on every client |
| Fallback | Nightly static snapshot, shipped with the page | 12:01am Central; yesterday, never blank |
A page that is already built cannot be slow to render or fall over under load, and the live numbers arrive after it, never instead of it.
Questions, answered.
Is my dashboard on a shared server?
No. It is a static site on Cloudflare's edge at your own hostname, behind an access gate and a seat check. The live numbers come from a managed cloud service.
What if TruLata's own machines are off?
Your page still opens and still shows the latest snapshot. Our machines pull and push; they are not in the request path. A Refresh while they are off ends in a reloaded page whose stamp says when the data was last pulled.
Are all clients on the same version?
Yes. The engine, styles and boot loader are shared files, a preflight checks every instance against the canonical copy before each deploy, and an engine change is rendered against every client before any of them sees it.
Can the browser reach your backend directly?
No. An edge function behind the access gate holds the secret and forwards the request. Your browser calls a path on your own hostname and never holds the secret.
What happens if a nightly pull fails?
Yesterday's page stays up. The job stops before the deploy on a failed pull or a script that does not parse, and a section whose source failed keeps its previous value.
Can any of this write to my accounts?
No. It reads, through manager access you grant. The four write paths on the screen go to people or to your own lead record, and none reaches your ad account, your CRM, your site or your Business Profile.
See it running
before you decide.
The demo is the real product on a fictional company, with no form in front of it. Pricing is three published tiers. Setup on your own accounts takes two to four weeks.
Open the live demo See pricing
New here? See what the Command Center is. Prefer to write? Send us the one thing you want to know.
- Refreshed when you open itLive data on page load, never a monthly PDF
- Counted from your own formsLeads recorded server-side, compared daily with Ads and GA4
- Four answer engines, measuredChatGPT, Gemini, Claude and Grok, with a published denominator
- A review-first queue on every sendEvery draft waits in a review-first queue and every send is logged.