"Multi-tenant" shows up on every SaaS pricing page. For agency performance work, the useful question is narrower: what changes on Tuesday morning when twelve client sites live in one workspace instead of twelve browser profiles and a shared spreadsheet?
We asked that after migrating a small dev team off the "one free PSI account per client" pattern. The product features (organisations, sites, pages, schedules) are documented on our main blog. This post is the habits layer: what multi-tenant multi site performance monitoring actually changes in standup, handoffs, and fire drills.
What multi-tenant means on an agency performance dashboard
In our usage, multi-tenant means one team login, many monitored properties, shared rules with per-site exceptions. Not "your client gets their own product account." Not "we paste the same API key into twelve cron jobs."
Before that model, portfolio web performance was a reconciliation task. Someone exported CSVs, someone else merged them, and the Monday question "who is red on mobile LCP?" took forty minutes before anyone fixed code.
After it, the question is a screen scan: which sites missed runs, which pages breached budgets, who owns follow-up. The dashboard is the system of record; the spreadsheet is optional export.
If you want the object model (organisation → site → page) and what the product surface looks like, read the multi-site dashboard spotlight. This piece stays on behaviour.
Monday standup: from client tabs to portfolio questions
Our standup used to open with "any fires?" and drift into whoever shouted loudest. With a portfolio view, we fixed a short script:
- Any site with no test in the last scheduled window? (stale data, not stale client.)
- Any budget breach still open from last week?
- Any new site added without an owner name in the notes?
That third item sounds administrative. It prevented the classic multi-tenant failure: fifty sites in the list, twelve people on the team, and three "mystery" properties nobody will touch in retro.
Portfolio questions also surface patterns single-client tabs hide. Three retail clients drifting on INP after the same tag manager update is a platform decision. One client's tab only shows one brand panicking.
Multi site performance monitoring: naming sites for humans
Multi-tenant only works if the site list reads like your retainer list, not like DNS archaeology.
We renamed entries to what account managers say on calls ("Northwind retail", not northwind-prod-uk). We archive sites when contracts end instead of leaving ghosts that turn every portfolio scan into noise. We add one line in site notes: primary contact and what "done" means for alerts (fix code vs email client vs wait for their deploy).
Those conventions are boring. They are also what separates a agency performance dashboard you trust from a dumping ground of hostnames you are afraid to delete.
Per-site exceptions without losing global discipline
Multi-tenant does not mean one threshold for everyone. A brochure site and a checkout-heavy shop should not share the same LCP budget. The operational shift is where those exceptions live: next to the site object, visible when you scan the portfolio, not in a wiki page titled thresholds_final_v7.md.
We set global defaults once (mobile + desktop schedule, baseline budgets, alert channel). We document exceptions at the site level with a reason ("client requested weekly only", "staging hostname, alerts off"). When someone goes on holiday, the substitute engineer reads the site note instead of paging the wrong client.
For setup steps and schedule choices, the automated PageSpeed monitoring for multiple sites guide covers the procedural side. Day to day, the win is exceptions you can see without opening five tools.
Handoffs: account team vs engineering
Multi-tenant dashboards fail when only engineers look at them. Our account leads do not tune Lighthouse configs. They do need to know whether last week's report still reflects reality.
We agreed a lightweight split:
- Engineering owns schedules, budgets, alert routing, and regression triage.
- Account owns site list hygiene (live vs archived), client comms when a breach is client-visible, and scheduling review calls when trends move.
The shared artifact is the site list plus last-run timestamps. Account can open a site, see green/red at a high level, and ask sensible questions. Engineering is not screenshotting PSI into Slack anymore.
That handoff is what "monitor multiple websites performance" means in practice. One portfolio, two roles, same numbers.
Fire drills: shorter path from email to URL
When a client emails "checkout feels slow", the old path was: find which PSI bookmark, guess mobile or desktop, wonder if anyone tested since the deploy.
The new path: open the named site, filter to checkout URLs, read last run and deploy notes, compare mobile vs desktop on the same row. Multi-tenant shortens the search phase. It does not replace debugging.
We still open deeper tools for traces and filmstrips. The dashboard answers "is this an ongoing regression or a stale test?" in under two minutes. That alone cut duplicate fire drills where two people ran the same manual PSI check unaware of each other.
Automated pagespeed monitoring setup: what we stopped doing
Moving to one workspace killed a few rituals that felt productive but did not scale:
- Rotating "PSI hero" weeks where one developer manually tested everyone's homepage.
- Per-client folders of PDF exports with no link to current schedules.
- Shared inbox alerts with no site name in the subject (mute follows quickly).
We kept weekly portfolio review as a calendar event. We dropped the pretence that everyone maintains their own bookmark bar as governance.
When multi-tenant is not enough
Honest limits:
- Deep diagnostics still need purpose-built tools.
- Full RUM still lives in analytics if the client pays for it.
- Client-facing logins may still be exports or shared reports until access controls mature.
Multi-tenant changes how your team operates internally. It does not replace every stakeholder view. We position it as the control plane for scheduled synthetic tests, not the entire observability strategy.
Next step: run one portfolio review with names and owners
Before you add site number thirteen, run this once:
- Open your site list (or build one if you are still on bookmarks).
- Mark each property active or archived; delete ghosts.
- Assign a human owner per active site.
- Note one per-site exception that matters (schedule, budget, or alert route).
- Ask the portfolio question: any site with no recent run or open breach?
If that review takes more than twenty minutes, your multi-tenant surface is probably fine but your naming and ownership rules need work, not another tool.
For product detail on organisations, sites, and pages, see Managing multiple client sites in one dashboard. For schedules, discovery, and budgets when you configure the portfolio, use How to set up automated PageSpeed monitoring for multiple sites.
Multi-tenant is the architecture. Tuesday morning is the proof.
Top comments (0)