Getting Started with Apogee Watcher: A Step-by-Step Setup Guide

You signed up for scheduled PageSpeed monitoring because manual PageSpeed Insights tabs do not scale. The gap is usually not motivation but sequence: which screen comes first, how many URLs belong in week one, and when budgets should start paging someone. What follows is a practical Apogee Watcher setup path from empty account to a site that runs on its own, with mobile and desktop lab results, optional CrUX context where Google publishes field data, and email when thresholds breach.

If you are onboarding a client under contract, pair these product steps with our agency onboarding workflow for kickoff, client comms, and day-thirty handoff. If you are comparing DIY Lighthouse CI with a managed product first, read How to Set Up Automated PageSpeed Monitoring for Multiple Sites for the broader build-versus-buy picture, then return here for the in-app clicks.

What you need before Apogee Watcher setup

Gather a short list before you open the dashboard. You will move faster and avoid re-work on URL scope.

You need a production hostname you are allowed to test (or a staging URL if that is explicitly in scope). You need three to fifteen priority paths, not every tag archive on day one: homepage, primary conversion URL, and a few template representatives. You need one internal owner for alerts and one decision on mobile versus desktop, which for most public sites means both strategies enabled. You need a rough cadence: daily for high-change properties, weekly for stable brochure sites; our guide on scheduling test frequency and priority across a portfolio explains quota trade-offs when you add more clients later.

You do not need a Google Cloud project or a PageSpeed Insights API key. Apogee Watcher holds that integration so your team configures sites inside the product instead of rotating keys per domain. You also do not need a JavaScript snippet on the site; monitoring is synthetic lab testing through PageSpeed Insights, plus CrUX when available for the URL.

Optional but useful: run the public free domain PageSpeed check on the hostname first. You get a multi-page snapshot and emailed report without configuring schedules, which helps you sanity-check discovery and pick starter URLs before you commit them to a recurring plan.

Create your organisation and sign in

Create a free account with the email that should receive billing and, by default, budget alert digests for organisation admins. After verification, you land in your organisation workspace: the container for sites, team members, quotas, and shared history.

Agencies usually keep one organisation and add a site per client rather than spinning up separate logins. Solo operators do the same with one site to start. If you expect several teammates to configure monitoring, skim team roles and access control before you invite anyone: Admins manage billing and membership, Managers tune sites and budgets, Viewers read results without changing settings.

Check plan limits in My Account if you are on a tier with caps on sites, monthly tests, or organisations. Upgrade or trim URL scope early so the first scheduled week does not hit quota mid-run.

Add your first site to monitor

From the dashboard, open Sites and create a site record for the property you are responsible for. Give it a name your team recognises (client brand plus environment if you run staging separately) and enter the canonical domain. The domain anchors discovery and URL validation; keep it aligned with the host users actually load in the browser.

One site equals one monitored property in Apogee Watcher. Homepage, pricing, and checkout paths live as pages under that site, not as three separate site records unless they truly belong to different hosts. When you later manage many properties, the multi-site dashboard is simply this pattern repeated with portfolio-level navigation.

Build your page list with discovery and manual URLs

Monitoring only works on URLs you list. You can add pages manually or run discovery from the site view.

Run Discover Pages

Use Discover Pages on the site when a sitemap exists. Watcher reads sitemap.xml and nested indexes first, then can crawl same-domain links if the sitemap is thin. Discovery respects caps on depth and URL count so a large estate does not import thousands of parameter variants in one pass. Review the results, deactivate noise (search facets, preview paths, admin routes), and keep conversion templates even if they sit deep in the crawl output. The product marks auto-discovered URLs so you can filter them later; see the page discovery spotlight for the full pipeline.

Add priority URLs by hand

Force-add anything discovery misses: campaign landers, freshly launched /pricing variants, or routes blocked from crawlers but public in production. A sensible first pass is one homepage, two to five conversion URLs, and five to ten template representatives. Expand after alert triage stays manageable.

Each page row controls whether mobile tests, desktop tests, or both run, plus a priority band that influences ordering in reports and digests. Enable both strategies unless you have a written reason to skip one; sponsors still ask about desktop even when analytics skew mobile.

Configure test schedule and priority per page

Scheduled testing is the core of Apogee Watcher setup. Open the site schedule settings and choose a cadence your plan allows: hourly for risky release windows, daily for active commerce, weekly for stable marketing sites. Match frequency to release risk, not equality across every URL on the account.

Set page priority so the URLs that drive revenue or leads surface first in roll-ups and alert summaries. A blog tag page rarely deserves the same priority as checkout. When you are unsure how aggressive to be, start conservative on URL count and daily cadence, then tighten after you see a week of quota usage in the dashboard.

Run your baseline PageSpeed tests

Before you rely on alerts, confirm data is flowing. Trigger a test run on priority pages or use the site action to test all active pages once. When results return, open a few rows and verify mobile and desktop series both populated where expected.

Record a lightweight baseline note outside the product if you are setting up for a client: date, owner, LCP, INP, CLS, and performance score on the top three URLs, plus one line on likely cause for any fail. Numbers without context do not survive the first review meeting. For metric definitions, use What Are Core Web Vitals? and LCP, INP, and CLS explained.

CrUX percentiles may appear beside lab scores when Google publishes field data for that URL and strategy. Treat CrUX as a lagging field signal; lab results from the same run are what budgets evaluate immediately after deploy.

Set performance budgets on the site

Budgets turn scores into pass-or-fail rules. Open the site budgets screen. Watcher creates default mobile and desktop budget rows per site; replace placeholder thresholds with numbers that match your contract or internal standard. Typical starting bands for marketing sites follow our performance budget thresholds template: LCP at or below 2.5 seconds, INP at or below 200 milliseconds, CLS at or below 0.1, and a minimum performance score you are willing to defend in a client call.

You can cap FCP and TBT as supporting lab metrics when INP or LCP regressions need faster diagnosis; see FCP and TBT: supporting metrics beyond Core Web Vitals if those fields matter for your stack. Deactivate a strategy’s budget row if you genuinely monitor only one form factor for that property.

Mark provisional thresholds in your internal notes for the first month. Tighten after you see how often deploys or third-party scripts trigger noise versus real regressions.

Turn on email alerts and confirm delivery

Alerts connect budgets to humans. Set the alert channel to email on the budget rows you want enforced. When a scheduled run finishes and violations exist, organisation admins receive a site-level digest listing the worst pages first, with counts for total breaches and breakdown by metric. Cooldown logic avoids repeating the same fire while a metric stays outside the band; details are in the performance budgets and email alerts spotlight.

Validate routing once: temporarily lower a threshold on a staging URL you control, run a test, confirm the digest arrives, then restore the real numbers. If mail does not arrive, check spam folders and confirm the recipient is an active organisation admin.

Slack and webhooks remain on the roadmap for many teams; email is enough to prove the loop during initial setup.

Invite teammates with the right roles

When more than one person will respond to regressions, invite them before the first client-facing review. Assign Admin only to people who should change billing and membership; give Managers to leads who tune budgets and schedules; use Viewer for account managers who need read access without risking accidental configuration changes.

Document internally who triages alerts versus who speaks to the client. Without that split, digests land in a shared inbox and regressions age quietly. For alert philosophy, read From Reactive to Proactive: How Smart Alerts Change Performance Monitoring.

What happens after setup: daily and weekly routines

Setup is complete when scheduled runs execute without manual PSI tabs, budgets reflect agreed thresholds, at least one person receives alert mail, and you can name three current actions from the baseline.

Daily, glance at new alerts. If none fired, note it and move on. Weekly, scan trends for gradual drift on priority URLs and adjust page scope if marketing shipped new templates. Monthly, generate or export client-facing summaries and revisit budgets using the monthly performance review template if you report on a fixed cadence.

Optional next layers, not required on day one: prospecting with domain reports, comparing tools for portfolio scale, or adding Lighthouse CI in development while Watcher watches production. Lighthouse CI vs managed monitoring covers that split for agencies.

Apogee Watcher setup for multiple client sites

The same sequence repeats per client site inside one organisation: add site, discover or list URLs, schedule, baseline, budgets, alerts. Standardise a starter URL pack per vertical (brochure, ecommerce, SaaS marketing) so delivery does not reinvent scope every kickoff. Keep one role map across clients so new hires know who may change thresholds.

When the portfolio grows past a handful of properties, resist separate logins per client. One organisation with strict site separation preserves quota visibility and lets you answer portfolio health questions from a single sites list, which is the operational habit described in our Core Web Vitals monitoring checklist for agencies.

FAQ

How long does Apogee Watcher setup take?

A single marketing site with ten to fifteen URLs, daily scheduling, and starter budgets typically fits one focused afternoon. Client onboarding with stakeholder email and role assignments may stretch across a week; that timeline is process, not product loading time.

Do I need a PageSpeed Insights API key?

No. Apogee Watcher uses the PageSpeed relationship on your behalf. You configure domains and pages in the dashboard.

Can I monitor staging or password-protected URLs?

You can add any URL the PageSpeed service can fetch. Staging hosts work when they are reachable from the public internet without auth walls. Authenticated app shells are a poor fit for synthetic lab monitoring; use first-party RUM there if the client requires session-level proof. See When to Use Synthetic vs Real User Monitoring for Performance for how to layer tools.

How many pages should I add on day one?

Start with ten to twenty priority URLs, not the entire sitemap. Expand after triage proves the alert path works.

What is the difference between this guide and the multi-site setup how-to?

The how-to compares approaches (DIY Lighthouse CI, managed platforms, hybrid workflows). This guide is the product-specific click path inside Apogee Watcher once you have chosen hosted monitoring.

Does setup include client reporting?

Setup covers measurement and alerts. Branded PDF reports and scheduled delivery depend on plan features; configure reports after the baseline run looks trustworthy.

Where do I get help if discovery returns too many URLs?

Deactivate low-value paths, lower discovery caps, and prefer manual adds for a tight first set. Re-run discovery after the client fixes sitemap quality if the estate publishes one.

---

Apogee Watcher setup boils down to organisation, site, pages, schedule, baseline, budgets, and alert routing. Run through that sequence once on a real domain and the product carries weekly measurement without another spreadsheet of PSI scores.

Start a free Apogee Watcher account and walk the steps above on your first site, or baseline a hostname with the free domain PageSpeed check before you add it to a recurring schedule.