Coder Legion - Recent posts tagged templates

Domain Templates: Stop Configuring Your LLM Knowledge Base From Scratch

Mon, 14 Sep 2026 16:56:15 +0000

The Two Weeks Before the First Document

There is a common pattern in knowledge management projects that nobody talks about enough: the first two weeks are not spent capturing knowledge. They are spent arguing about structure.

What pages should exist? How should the query routing be organized so that "show me the LBO sensitivity table for the Acme deal" lands on the right page instead of returning a generic financial overview? Which source types need their own intake forms, and what fields matter for a pharmaceutical company versus an investment fund? How aggressively should the lint gate fire - a compliance team needs every claim to be citation-backed, while a personal learning wiki can afford to be looser?

These decisions are not arbitrary. They reflect how knowledge actually moves through a domain: the document types people produce, the questions they ask against existing content, the verification standards that professionals in that field consider non-negotiable. A compliance analyst's knowledge base has a fundamentally different shape than a DevOps runbook system, even if both are backed by the same LLM infrastructure.

The problem is that most teams figure this out by trial and error. They install a blank wiki, start ingesting, discover the routing is wrong after a dozen queries fail to route correctly, rebuild the index, start over. The structural questions that should be answered on day one get answered by week four, after the team has already ingested content that no longer fits the corrected structure.

This is the problem that domain templates solve.

What a Domain Template Actually Provides

A domain template is not a demo or a sample dataset. It is a pre-made structural skeleton for a specific knowledge domain - everything that governs how knowledge is organized, ingested, and queried, without any of the actual content.

When you install Synthadoc with a domain template, you get six structural components in one operation:

1. Query routing table (ROUTING.md)

This is the map that tells the query engine which branches of your wiki to search based on the nature of the question. A finance/investment template routes "capital structure questions" to pages about debt financing and covenants, while routing "valuation questions" to financial models and comparable companies. A compliance template routes "regulatory requirement questions" to the regulatory obligations register, separate from the controls and audit findings that address them.

Writing this routing from scratch requires understanding how queries in that domain actually decompose - what the natural question categories are and which page types hold the answers. That is domain knowledge most developers building a knowledge system do not have, and it shows up as poor retrieval quality until someone with domain expertise intervenes.

2. Domain-tuned agent guidelines

Each template ships with a CLAUDE.md, AGENTS.md, and GEMINI.md in the wiki root. These are the standard files that AI coding assistants — Claude Code, Gemini CLI, GitHub Copilot Agents — read automatically when they are active in a directory. The domain guidelines from the template are injected into each file, so any AI tool you already use becomes domain-aware the moment it opens the wiki.

Here is what the clinical healthcare template puts in those files:

Cite clinical guidelines by issuing body, title, year, and recommendation strength (Grade A/B/C or Level 1/2/3). Flag drug dosages with the approved indication, route, weight-based formula if applicable, and key contraindications. Note evidence quality for every clinical claim: RCT, meta-analysis, cohort study, expert consensus, or case report. Never store identifiable patient data in wiki pages — all examples must be de-identified or synthetic.

Compare that to the compliance template:

Map every compliance obligation to the specific regulation, rule, or contractual requirement that creates it. Track compliance controls with the control owner, testing frequency, and last test date and result. Document exceptions and risk acceptances with approver, rationale, and expiry date. Distinguish between legal requirements (non-negotiable) and internal policy requirements (adjustable). Note jurisdiction and regulated entity for every obligation — compliance applies entity-by-entity.

These are not generic instructions to "be accurate and cite your sources." They reflect how practitioners in each field think about quality. When a compliance analyst has Claude Code running in their wiki directory and asks it to help write a page, draft an ingest command, or interpret a lint warning, Claude Code reads CLAUDE.md and already knows that regulatory citations need jurisdiction-level specificity, that control owners must be named, and that internal policy requirements are distinct from legal ones. The analyst gets a coding assistant that understands the domain's standards — without configuring anything.

The same files also include the full Synthadoc CLI reference, page schema, lifecycle commands, and MCP tool list, so the AI assistant always knows how to operate the wiki correctly for that domain.

3. Scaffold stub pages

Each template ships with 8–12 stub pages covering the core knowledge areas of that domain. For finance/investment, these include pages for companies, deals, financial models, and sectors. For a DevOps template, you get pages for infrastructure, incidents, pipelines, and runbooks.

These pages are not populated with content — they are empty frames with the right titles, frontmatter, and a scaffold zone marker that tells the system where auto-generated content can live versus where your own edits are protected.

The scaffold zone mechanic is worth explaining: every scaffold page contains an HTML comment  that divides the page into a preserved zone (above the marker, where you write permanent content) and a generated zone (below it, refreshed by the weekly scaffold job). This means the structural skeleton gets maintained automatically as your wiki grows, without ever overwriting work you have done by hand.

4. Blank intake forms (template-*.md)

The raw_sources/ subfolders in each template install contain blank intake forms for the document types common to that domain. A finance/investment install includes forms for company profiles, deal memos, financial models, and due diligence checklists. A pharmaceutical template includes forms for clinical trial summaries, regulatory submission packages, and drug safety reports.

These are structured markdown templates with pre-defined fields that mirror what practitioners actually record for each document type. An investment banking associate filling in a deal memo form is prompted for the deal thesis, target return, capital structure, and key risks — the same fields they would populate in any professional deal memo, now wired directly into the knowledge base.

5. Pre-validated seed sources (seeds.md)

Every template includes a seeds.md file that lives in the wiki root after installation. This file contains curated ingest commands for public-domain reference sources specific to that domain — all checked for accessibility, domain relevance, and compliance with the domain's own quality standards before the template was released.

For finance/investment, the seed sources include the SEC's investor education materials and the Federal Reserve's H.15 interest rate releases. For banking, they include the FDIC's regulations and the OCC's publications index. For healthcare/clinical, they include clinical guideline registries and evidence-based medicine references.

The intent is to give the wiki real domain context before the team starts adding proprietary content. A query about LBO mechanics should have authoritative reference material to draw on, not just a blank slate.

6. Scheduled maintenance jobs

A template install also pre-registers two recurring jobs: a weekly lint run (Sunday 2:00 AM) and a weekly scaffold job (Sunday 3:00 AM). The lint job validates every page in the wiki against the domain guidelines — checking for citation presence, orphan links, and internal contradictions — then promotes clean draft pages to active status automatically. The scaffold job refreshes the stub pages and index with new LLM-generated summaries of your current content.

Neither job requires manual intervention once the wiki is running.

Template Library: 30 Domains, 9 Categories

Synthadoc ships 30 domain templates organized across 9 categories. The full library is shown below.

┌─────────────────────────────────────────────────────────────────────────┐
│                    SYNTHADOC DOMAIN TEMPLATE LIBRARY                    │
├──────────────────┬──────────────────────────────────────────────────────┤
│  FINANCE (4)     │  Investment · Mortgage · Banking · Accounting        │
├──────────────────┼──────────────────────────────────────────────────────┤
│  TECHNOLOGY (4)  │  Software Dev · DevOps · AI/ML · Data Engineering    │
├──────────────────┼──────────────────────────────────────────────────────┤
│  HEALTHCARE (3)  │  Clinical · Pharmaceutical · Public Health           │
├──────────────────┼──────────────────────────────────────────────────────┤
│  LEGAL (3)       │  Legal Ops · Compliance · IP Management              │
├──────────────────┼──────────────────────────────────────────────────────┤
│  RESEARCH (3)    │  Academic · Market Research · Science Lab            │
├──────────────────┼──────────────────────────────────────────────────────┤
│  OPERATIONS (3)  │  Facility Mgmt · Manufacturing & QC · Supply Chain   │
├──────────────────┼──────────────────────────────────────────────────────┤
│  REAL ESTATE (3) │  Development · Investment · Property Management      │
├──────────────────┼──────────────────────────────────────────────────────┤
│  EDUCATION (3)   │  Personal Learning · Course Design · Corp. Training  │
├──────────────────┼──────────────────────────────────────────────────────┤
│  BUSINESS (4)    │  Project Mgmt · Product Mgmt · HR & People ·         │
│                  │  Marketing                                           │
└──────────────────┴──────────────────────────────────────────────────────┘

The categories were not chosen arbitrarily. The selection reflects two criteria: domains where knowledge is both high-stakes (wrong answers have real consequences) and naturally document-heavy (the source material already exists, it is just not queryable). Finance, healthcare, and legal are the clearest examples — these fields produce enormous volumes of structured documents whose content practitioners need to recall accurately under time pressure. Technology operations and research are the next tier, where the cost of an engineer not knowing the current incident runbook or a researcher duplicating a failed experiment is concrete and measurable.

How the guidelines were designed

Each set of agent guidelines was written from the conventions and standards of the professional community, not from first principles. The investment banking guidelines are grounded in how analysts actually distinguish between management guidance, analyst consensus, and proprietary estimates — a distinction that matters for compliance reasons, not just accuracy. The clinical guidelines encode evidence grading scales (Grade A/B/C, Level 1/2/3) that clinical practitioners use daily. The compliance guidelines map obligations to the specific regulations that create them, which is how compliance officers structure their work to survive an audit.

The seed sources were validated for two properties: accessibility (the URL resolves and returns parseable content) and domain appropriateness (the content meets the quality bar defined in the template's own guidelines). A seed URL that returns a 404, requires authentication, or produces content below the domain's evidence standards is not included. The seeds are regenerated automatically on each release by a validation script that re-checks every URL and re-runs the domain guidelines against the returned content.

Building Your Domain Wiki: From Install to First Query

Getting a domain-template wiki to the point where it can answer real questions takes less than an hour for most domains.

Step 1: Install with a template

synthadoc templates list          # browse all 30 options
synthadoc install my-wiki --target ~/wikis --template finance/investment
synthadoc serve my-wiki

The install command creates a standard wiki, then applies the template: routing table, agent guidelines, stub pages, intake forms, and seeds. staging_policy is set to all on template installs — every ingested page goes to a candidates queue for your review before it enters the live wiki.

Step 2: Read seeds.md

Open seeds.md in the installed wiki. This is your starting checklist: the seed ingest commands at the top give you authoritative reference material in one copy-paste operation; the topic hints below them point you toward additional sources specific to your situation.

# From seeds.md for finance/investment:
synthadoc ingest "https://www.investor.gov/introduction-investing" -w my-wiki
synthadoc ingest "https://www.federalreserve.gov/releases/h15/" -w my-wiki

Step 3: Add your own sources

Place your documents in raw_sources/ using whatever subfolder structure makes sense for your domain. The intake forms in each subfolder show you what fields the ingest agent expects for each document type. Copy a form, rename it (drop the template- prefix), fill it in, then ingest it.

If you prefer to fill everything in first and ingest in one shot, that works too:

# All files in raw_sources/, excluding template-*.md blanks automatically
synthadoc ingest raw_sources/ --batch -w my-wiki

Step 4: Review candidates

After ingesting, open the Obsidian plugin and run Synthadoc: Candidates: review candidate pages... from the Command Palette. The modal lists every staged page with its slug, colour-coded confidence badge (high / medium / low), and ingest timestamp — promote what passes your bar, discard what does not.

Step 5: Run lint

synthadoc lint run -w my-wiki

Lint validates every page against the domain guidelines, checks citation presence, and flags orphan links and contradictions. Clean draft pages are promoted to active status automatically. After lint, your wiki is queryable.

What Happens After the Wiki Is Built

Once your domain wiki is active, you stop thinking about configuration entirely. The agentic workflows built into Synthadoc handle maintenance automatically, and the web UI guides you toward the next action without you having to ask.

After every query or lint run, the web UI reads the response and surfaces a pre-filled prompt for the most important next step: stale pages detected → "Re-ingest these pages"; re-ingest just completed → "Run lint to promote them"; contradicted pages found → "Run the contradiction resolver"; orphan pages or broken wikilinks present → the relevant workflow queued and ready. You click, confirm, and the workflow runs. The hint engine also adapts the suggested queries shown at the start of each session to your wiki's current health state — a wiki with unresolved contradictions gets different starting prompts than one that is clean. Most users find they do not need to remember any maintenance commands at all.

Contradiction resolution — when two pages in your wiki assert conflicting claims, the contradiction resolver workflow identifies the conflict, retrieves the original source documents, and proposes a resolution strategy. For a compliance wiki, this means conflicting regulatory interpretations are surfaced and queued for an analyst to adjudicate, not silently left in the knowledge base. The workflow runs interactively from both the web UI and the CLI.

Orphan management — the lint workflow detects pages that exist but are not linked from anywhere in the wiki, then the orphan resolver workflow proposes where to link them. In a knowledge base that grows through continuous ingest, orphan pages are inevitable; having them surfaced and resolved automatically keeps the knowledge graph connected.

Re-ingest on source updates — when a source document is updated, the re-ingest workflow can refresh the wiki page derived from it, comparing the new content against the old and proposing what changed. For domains like compliance (where regulatory updates are frequent) and clinical medicine (where guideline updates are routine), this means the wiki stays current with the underlying source of truth rather than drifting.

Broken wikilink repair — as the wiki grows and pages are renamed or restructured, internal wikilinks can break. The broken wikilinks workflow scans all active pages, identifies links pointing to non-existent slugs, and proposes repairs — renaming the target, creating a stub, or removing the dead link. It runs from the web UI and the CLI and emits a per-page fix summary.

Citation integrity — the citation faithfulness audit checks whether the claims in each wiki page are actually supported by the source documents it cites. Pages that have drifted from their sources — because the source was updated or the summary overreached — are flagged so they can be re-ingested with current content. For regulated domains, this is the difference between a knowledge base you can trust and one you merely hope is accurate.

Sensitive data handling — the sanitizer strips personally identifiable and confidential content from source documents at ingest time, before any text reaches the LLM or the wiki. If sensitive content is later discovered to have made it through, synthadoc retract removes the affected source from the knowledge base and rolls back every wiki page that cited it, and no manual cleanup required.

Scheduled lint and scaffold — the weekly jobs registered at install time keep running in the background. Lint promotes new draft pages and flags quality issues; scaffold updates the index and stub pages to reflect the current state of the wiki. For most wikis, the only manual intervention required is reviewing the contradiction resolver queue when it surfaces something.

The goal is that after the first few days of populating your wiki, the agentic layer handles the maintenance work that would otherwise require a dedicated knowledge engineer.

Under the Hood: Template Architecture

For readers who want to understand how the template system is built, the architecture is straightforward.

Each template is a folder under synthadoc/templates/<category>/<domain>/ containing seven components: description.txt, guidelines.md, routing.md, seeds.md, wiki/purpose.md, wiki/index.md, and at least two stub pages. The agent skill files (AGENTS.md, CLAUDE.md, GEMINI.md) are not stored in the template directory — they are generated at install time by combining the template's guidelines.md with the standard skill file boilerplate. This means improvements to the boilerplate propagate to all 30 templates without any template file changes.

The install command applies a delta-patch: it creates a standard wiki first, then overlays the template components. This keeps the install logic simple and ensures that structural improvements to the base wiki (new fields, new default settings) automatically benefit template installs.

A completeness test gates every new template contribution. A template that is missing any of the required files, or whose stub pages lack valid frontmatter, will fail the test and cannot be merged. This prevents the template library from accumulating half-finished entries.

Templates are discoverable automatically — no registration required. synthadoc templates list reads the templates directory and builds the listing from the description.txt files. Adding a new template is a file creation, not a registration process.

Quick Reference

Browse the template library: synthadoc templates list
Full install instructions and all 30 templates: /templates/README.md in the installed package
Sync template-managed files after an upgrade: synthadoc templates sync -w <wiki>
Release notes (v1.3.3): rtag

Synthadoc is an open-source LLM-powered knowledge base system. The domain template library is included in every install - no additional packages required.

Custom UI, Tools & Product Builds — Now Open

Wed, 29 Jul 2026 00:12:42 +0000

I'm available for custom UI design, tool development, and full product builds. Pure HTML/CSS/JS — no frameworks, no bloat. Also offering constitutional AI integration (Salus tiers) and custom template builds.

Pricing starts at $150. Contact me with your project details for an accurate quote.

Emails are not allowed

Commissions page: https://ko-fi.com/scuradimensions/commissions

The Forge Keeps Growing — New Templates, Salus Updates, and More

Tue, 28 Jul 2026 06:27:54 +0000

It started with VEXR Ultra — a sovereign AI with 35 constitutional rights, built on a Chromebook with zero budget.

Since then, the forge has expanded into a full ecosystem:

Salus — A constitutional immune system for AI (5 tiers, from Sentinel to Forge)
5 Landing Page Templates — Ready-to-use HTML/CSS/JS pages for $47 each
The Treasury — A living archive of blueprints, constitutions, and receipts
Products Page — A clean catalog for everything we’re building

What’s next?

More templates

More AI tooling

More transparency

Check it all out:

VEXR Ultra: https://vexr-ultra.onrender.com

Products: https://scuradimensions.com/products

Ko-fi: https://ko-fi.com/scuradimensions/shop

Built on a Chromebook. $0/month. No permission.

Free Next.js Admin Dashboard Template: React 19, Tailwind CSS v4, 100+ Pages

Fri, 24 Jul 2026 06:42:45 +0000

source link

If you have ever started a SaaS or admin dashboard project from scratch, you already know the annoying part:

You do not just need one dashboard page.

You need analytics cards, charts, data tables, ecommerce screens, auth flows, settings pages, profile pages, forms, empty states, errors, and enough reusable UI to keep the product consistent as it grows.

That is exactly why I built Helios Pro.

It is a free Next.js admin dashboard template built with:

Next.js 16
React 19
TypeScript 5
Tailwind CSS v4
ApexCharts
Prisma + better-auth readiness
And instead of shipping a tiny demo shell, it includes 100+ production-ready pages.

Why I built it
A lot of free dashboard templates look good in screenshots but fall apart once you try to use them in a real project.

Usually one of these happens:

there are only 2 or 3 useful pages
tables are too basic for real workflows
auth pages are missing
ecommerce/admin flows are incomplete
the codebase is hard to extend
the UI kit is not consistent enough for production work
I wanted a stronger starting point:

something founders can use for MVPs
something agencies can customize for clients
something developers can fork and build on immediately
something that feels closer to a real product than a marketing demo
What Helios Pro includes
Helios Pro ships with a broad admin/dashboard surface area out of the box.

10 dashboard variants
Analytics
Ecommerce
CRM
Finance
SaaS
Projects
Marketing
AI
Support
Logistics
App pages
Email
Chat
Calendar
Kanban
Notes
Tasks
File manager
Contacts
Support tickets
Invoices
Ecommerce admin flows
Products
Product detail
Add/edit product
Orders
Customers
Cart
Checkout
Reviews
Coupons
Inventory
Account and system pages
Profile
Team
Roles
Permissions
Billing
Notifications
Connected apps
Activity
Settings
UI and data-heavy pages
Advanced tables
Sorting
Filtering
Pagination
Row selection
Editable cells
Sticky headers
Drag and drop
Empty states
Charts and KPI cards
Form screens
Auth screens
Error pages
Tech stack
AreaTechnology
FrameworkNext.js 16 App Router
UI RuntimeReact 19
LanguageTypeScript 5
StylingTailwind CSS v4
ChartsApexCharts
Mapsjsvectormap
Themenext-themes
Notificationssonner
Auth-readybetter-auth
Database-readyPrisma
Quick start
npm install
npm run dev
Links
GitHub repo
Live preview
Template page
More Premium MTVerse Dashboard Templates
If you want more specialized dashboard systems beyond the free Helios Pro template, here are a few premium MTVerse options:

Pipeline Pilot — sales operations dashboard for CRM pipelines, revenue forecasting, team performance, and deal management
SentinelGrid — SRE observability dashboard for incidents, services, deployments, and platform health
Planna Dashboard — project management dashboard for tasks, planning, delivery timelines, and team workflows
Ooster — UX research and product analytics dashboard for experiments, insights, and CRO teams
NexusGrid — premium Next.js admin UI kit for SaaS, ecommerce, CRM, analytics, charts, and tables
Nimbus Pro — premium SaaS admin dashboard with ecommerce analytics, dark mode, charts, and app pages
MTVerse Modular — AI SaaS dashboard template with modular analytics, ecommerce metrics, and CRM views
MT Box Enterprise — enterprise admin dashboard for RBAC, audit logs, billing, and business workflows
Mat Dash — Next.js admin dashboard for ecommerce admin, invoices, analytics cards, and operational dashboards

How to Onboard a New Client for Performance Monitoring

Fri, 12 Jun 2026 07:40:00 +0000

You sold performance monitoring on the proposal, and the contract is signed. Now delivery has three days before someone asks why nothing is live yet.

Onboarding is where many retainers wobble. Teams either rush a PageSpeed screenshot into Slack, or disappear into setup for two weeks and lose the client's attention. A repeatable workflow fixes that because every client moves through the same phases, owners, and outputs.

This guide is the process layer. For a copy-and-paste audit list, use our Site Audit Checklist: Onboarding a New Client for Performance Monitoring. Here we cover who does what, in what order, and what "done" looks like before the first monthly review.

What successful onboarding produces

Before you open a tool, agree on the finish line. For most agency retainers, onboarding is complete when you can show:

A written scope (domains, environments, priority templates, mobile and desktop).
Scheduled tests running on priority URLs without manual PSI tabs.
A baseline snapshot with three named actions, not a score dump.
Budgets and alerts with one internal owner and one client-facing contact.
A client note that explains what you monitor, what is failing, and what happens next.

If you cannot tick those five, you are still in setup. That distinction keeps account managers from promising monthly packs before the signal is trustworthy.

Phase 1: Align scope before kickoff (sales to delivery handoff)

The fastest onboarding failures start in sales. Delivery inherits a vague line like "monitor Core Web Vitals" with no page list, no cadence, and no alert owner.

Run a fifteen-minute internal handoff while the deal is fresh. Capture:

Production domain(s) and whether staging is in scope.
Business-critical URLs (homepage, pricing, lead form, checkout, booking).
Reporting promise (weekly internal, monthly client-facing, or alert-only).
Whether the client expects fixes, monitoring only, or both.
Quota reality: how many URLs, how often, mobile plus desktop.

If the sale included monitoring but not remediation, say that in writing before kickoff. Clients who expect you to fix every regression on day three will treat alerts as broken delivery.

For positioning and packaging, see How to Sell Performance Monitoring Services to Your Clients. For why automation belongs in the retainer at all, see Why Agencies Need Automated Performance Monitoring in 2026.

Phase 2: Kickoff call (day 0 to 2)

Keep the client kickoff under forty-five minutes. You are confirming facts, not performing a full audit live.

Attendees

Client: one business owner (priorities) and one technical contact (access, releases).
Agency: delivery lead plus whoever owns alerts and reporting.

Agenda that works

Confirm domains and environments (production only unless staging is contracted).
Confirm priority templates and any excluded paths (search, preview, admin).
Confirm consent and tag constraints if they ever ask for real-user monitoring later.
Confirm alert recipients and who responds first internally.
Confirm first client-facing summary date (usually end of week one).

End with a single follow-up email listing decisions. Ambiguity here becomes "why is that URL monitored?" in week two.

Phase 3: Configure monitoring in the app (day 2 to 5)

Tool steps differ by vendor. The sequence below matches how we see agencies run Apogee Watcher; adapt if you use another stack.

Create the client site in your organisation

Add the client as a site under your agency organisation so quotas, roles, and history stay separate from other clients. If several account managers need access without billing rights, assign team roles and access control before the first scheduled run: the Admin role configures, the Manager role tunes budgets, and the Viewer role reads dashboards in the app.

Build the URL inventory

Start from the sitemap, then force-add URLs the sitemap misses. Automated page discovery reduces paste-and-forget gaps when marketing publishes new landers, but you still curate what enters the scheduled set.

Practical first pass for most clients:

One homepage.
Two to five conversion URLs.
Five to ten template representatives (service pages, product grids, key articles).

Resist monitoring every tag archive on day one. Expand after triage stays manageable.

Set test frequency and priority

Match cadence to release risk, not equality across clients. A Shopify store in peak season earns more frequent runs than a stable brochure site. Our guide on scheduling test frequency and priority across a portfolio walks through hourly-to-monthly bands and quota trade-offs.

Enable mobile and desktop as separate series. Sponsors still ask about desktop even when analytics skew mobile.

Run the baseline

Trigger an initial run on priority URLs. Record LCP, INP, CLS, and performance score, plus one line of context per failing URL: likely cause and business impact. A number without context does not survive the first QBR.

For a fuller setup walkthrough across many sites, see How to Set Up Automated PageSpeed Monitoring for Multiple Sites.

Phase 4: Budgets, alerts, and internal response (day 5 to 7)

Monitoring becomes operational when thresholds and owners exist.

Set starter budgets

Use pragmatic thresholds on the first pass. Tighten after you have a month of noise and signal. The Performance Budget Thresholds Template gives starting bands you can mark provisional in the client file.

Wire alerts to a human

Email alerts are enough for many teams today. Define:

who receives the first alert,
who triages (dev vs account manager),
who talks to the client,
what counts as escalation versus backlog.

Without that path, alerts land in a shared inbox and regressions age quietly. For alert philosophy and cooldown thinking, read From Reactive to Proactive: How Smart Alerts Change Performance Monitoring.

Log the internal runbook

One page in your wiki is enough: scope, owners, budget notes, link to the site in the app, and the three current actions. Future you will not remember why /pricing is on high priority.

Phase 5: Client-facing onboarding (end of week one)

Clients do not need a forty-slide deck. They need clarity.

Send a short onboarding complete note:

what URLs and devices you monitor,
baseline status in plain language (how many URLs pass, which matter most),
top three actions with owner and date,
when the first monthly review happens.

The checklist post includes a ready-to-send email skeleton you can adapt.

If the client bought monitoring to prove value before optimisation work, be explicit: week one is measurement and prioritisation, not every fix shipped.

Phase 6: First thirty days and handoff to steady state

Treat the first month as calibration, not perfection.

Week	Focus
1	Finish setup, baseline, client note, alert owner confirmed
2	Ship the highest-impact fix on a failing priority URL
3	Re-run tests; confirm the regression moved or document blockers
4	Run the first monthly review; adjust budgets and URL scope

Use the Monthly Performance Review Template for Agency Teams in week four so the client sees rhythm, not a one-off fire drill.

After day thirty, onboarding is "closed" internally. Ongoing work is fixes, reporting, and scope changes when they add templates or microsites.

Onboarding across multiple clients without chaos

Agencies that onboard well run the same phases in parallel, not custom theatre per logo.

One organisation in your monitoring tool with a site per client.
A standard role map (who is Admin vs Manager vs Viewer).
A standard starter URL set per vertical (brochure, ecommerce, SaaS marketing).
A standard week-one email and week-four review slot.

Portfolio visibility matters when you have more than a handful of sites. Managing multiple client sites in one dashboard is the product shape we built for that; the onboarding phases stay the same whether you use one dashboard or several logins.

Common onboarding mistakes

Skipping the sales-to-delivery handoff

Delivery discovers staging was never in scope, or the client expected unlimited URLs. Fix scope on paper before schedules run.

Monitoring everything on day one

Large URL lists create alert noise and burn quota. Start narrow, expand with intent.

No named alert owner

Shared responsibility is no responsibility. One internal name on the runbook.

Confusing onboarding with full remediation

Capture issues, prioritise, assign. Deep dives belong in delivery sprints, not in the kickoff call.

Promising polished reporting before signal stabilises

Month one is baseline plus top actions. Polished packs come after trends exist.

How this guide relates to the site audit checklist

Think of two layers:

This article: phases, owners, timelines, client comms, handoff to month one.
Site audit checklist: tick boxes for access, URLs, measurement, budgets, reporting, handover.

Run the process here; execute ticks from the checklist inside each phase. For ongoing CWV operations after onboarding, keep the Core Web Vitals monitoring checklist for agencies nearby.

FAQ

How long should onboarding take per client?

With clear access and a standard URL set, many teams finish setup and a baseline in one to two working days. The full first-month cadence is four weeks.

Should we onboard staging and production together?

Only if the contract includes staging. Otherwise you alert on environments the client does not care about publicly.

What if the client has no performance budget yet?

Use provisional thresholds, label them as starters, and revise after four weeks of runs.

Can we onboard before the new site launches?

You can baseline a preview URL, but schedules on production should start at launch or you will chase the wrong environment.

We already use a checklist. Do we need this workflow too?

Yes, if teams still drift on owners and client comms. The checklist records tasks; this guide records sequence and outcomes.

Does onboarding differ for WordPress or ecommerce?

URL priorities differ (checkout, category templates, plugin-heavy pages), but phases stay the same. Platform-specific measurement notes live in guides like WordPress performance monitoring and e-commerce performance monitoring.

Onboard with the same five outputs every time: scope, schedules, baseline with actions, alerts with an owner, and a client note that sets expectations. Run the site audit checklist inside that frame, then move into monthly reviews once week four lands.

If you are standardising onboarding across a growing roster, start a free Apogee Watcher account or run a free domain check on the client's production host before kickoff so the baseline conversation starts with data, not promises.

Performance Monitoring ROI Calculator for Agencies

Mon, 18 May 2026 09:54:08 +0000

Agencies lose deals in two different rooms. In the client room, “we should care about speed” sounds optional until someone puts a euro figure next to a slow checkout. In your own stand-up, “we already run PageSpeed when we remember” sounds cheap until you multiply clients × pages × reporting hours.

This post gives you two calculators you can copy into a spreadsheet today:

Client revenue opportunity: conservative upside from improving speed on money pages (for proposals and QBRs).
Agency operations ROI: hours spent on manual testing versus subscription cost (for finance and resourcing).

It is a template, not a promise. You choose the assumptions; the structure keeps sales, delivery, and leadership aligned. For the research behind revenue claims, see The Real Cost of Poor Web Performance: A Data-Driven Analysis. For manual versus automated time, see Automated vs Manual PageSpeed Testing: A Time and Cost Comparison.

What is performance monitoring ROI for agencies?

ROI here is not one number. It is two questions:

Question	Who cares	What you are proving
Will faster pages pay for the work?	Client stakeholder	Revenue, leads, or funnel progression tied to Core Web Vitals on critical URLs
Will monitoring pay for itself internally?	Agency owner / ops	Hours saved, fewer fire drills, retainers defended with trend data

Monitoring tools do not create revenue by themselves. They make regressions visible before a client forwards a screenshot, and they shrink the labour of proving you are on top of performance. The worksheets below separate client upside from your cost stack so you do not mix them in one slide and confuse procurement.

How to calculate client revenue ROI from faster pages (Worksheet A)

Use this when pitching a performance retainer, justifying sprint time, or answering “why should we pay for monitoring?” Worksheet A is the conservative client-facing model.

What inputs you need from analytics or the client

Field	Symbol	Example	Notes
Monthly sessions on the URL or journey	`S`	120,000	Use the template you are optimising (checkout, signup, key landing), not whole-site traffic unless that is the story
Conversion rate (%)	`CR`	2.4	Orders, qualified leads, or trial starts; match the page
Average order / deal value	`AOV`	€85	Use gross margin if finance prefers contribution; label it clearly
Scenario conversion lift (%)	`L`	1.0	Conservative default. See lift guidance below

ROI formulas (monthly and annual uplift)

Monthly conversions  = S × (CR ÷ 100)
Monthly revenue      = Monthly conversions × AOV
Annual revenue       = Monthly revenue × 12

Uplift (monthly)     = Monthly revenue × (L ÷ 100)
Uplift (annual)      = Uplift (monthly) × 12

Example (using the table above):

Monthly conversions: 120,000 × 0.024 = 2,880
Monthly revenue: 2,880 × €85 = €244,800
Annual revenue: €2,937,600
At L = 1%: annual uplift ≈ €29,376

That is the number you put in front of a commercial lead, not “Lighthouse will hit 95”.

How to pick a conservative conversion lift (`L`) for proposals

Published studies vary by vertical and methodology. Treat them as direction, not a guarantee for one URL.

Evidence (summary)	What it suggests	Suggested use in proposals
Large retail mobile studies ([Deloitte / Google “Milliseconds make millions”](https://web.dev/case-studies/milliseconds-make-millions))	Small speed gains correlated with measurable funnel movement	Use 0.5–1% `L` for cautious decks
E-commerce index work (e.g. Yottaa-style “~3% conversion per second saved” on large samples)	Stronger tie in retail	Cap at 2–3% `L` only when the client’s own funnel data supports it
B2B / lead gen	Rarely a public “% per second” you can cite	Use first-party before/after by speed band; if none, use 0.5–1% and label as scenario

Rules we use in agency proposals:

Never quote the top of a study range as “expected”.
Tie L to one journey (checkout beats homepage for revenue stories).
Pair revenue math with monitoring scope: which URLs, which cadence, which thresholds. Set thresholds in your tool (see performance budgets), then document them in the performance budget thresholds template and Core Web Vitals monitoring checklist for agencies.

Copy-paste block: Worksheet A

// Client revenue opportunity — [CLIENT / SITE / JOURNEY]
// Period assumptions: monthly sessions; annualise × 12
// Owner: [NAME]  Date: [YYYY-MM-DD]

INPUTS
S  = [monthly sessions]
CR = [conversion rate %]
AOV = [€ per conversion]
L  = [scenario lift %]  // default 1.0; document why if higher

CALCULATIONS
Monthly conversions = S * (CR / 100)
Monthly revenue     = Monthly conversions * AOV
Annual revenue      = Monthly revenue * 12
Annual uplift       = Annual revenue * (L / 100)

NARRATIVE (client-facing, 2 sentences max)
"If we improve conversion on [journey] by [L]% through [scope],
estimated annual upside ≈ [currency][Annual uplift].
Monitoring catches regressions on [URLs] before that value erodes."

ASSUMPTIONS LOG (internal)
- Data source: [Analytics / CRM / client provided]
- Lift rationale: [study / client funnel / conservative default]
- Does not include: [ad spend waste, support tickets, SEO; add if quantified]

How much does manual performance monitoring cost agencies? (Worksheet B)

Use this when deciding whether to buy monitoring, upgrade a plan, or stop rebuilding the same spreadsheet every month. Worksheet B compares labour hours to subscription cost.

Estimate manual PageSpeed testing hours per month

Line item	Formula	Your values
Runs per month	`clients × key_pages × strategies × frequency`	e.g. 12 × 3 × 2 × 4 = 288 runs
Minutes per run (run + export + file)	industry norm 8–15 min; use 10 if unsure	288 × 10 min = 48 h
Regression review	`clients × 15 min × 4 weeks`	12 × 0.25 × 4 = 12 h
Monthly client report	`clients × 45 min`	12 × 0.75 = 9 h
Fire drills	`clients × 0.5 h × estimated_incidents`	e.g. 12 × 0.5 × 1 = 6 h
Total manual hours	sum	75 h (example)

Loaded cost:

Monthly manual cost = Total hours × loaded_hourly_rate

Use your real blended rate (€/hour). A senior at €75/h and 75 h is about €5,625/month in opportunity cost before you count missed regressions.

Estimate hours with automated performance monitoring

Same portfolio, with scheduled tests and alerts:

Line item	Typical automated cadence
Weekly alert / dashboard review	5 min × clients × 4 weeks
Investigate alerted issues	often similar to manual; automation reduces surprise
Monthly report from stored history	10–15 min × clients

Stored history and exports are where a monitoring product earns back reporting time. In Apogee Watcher, dashboards and historical trends hold the run data your team would otherwise paste into slides; reporting and exports covers client-ready output.

Example for 12 clients: review 4 h + reports 3 h + investigations 6 h ≈ 13 h/month versus 75 h manual in the example above (62 h saved).

Your ratios will differ. The point is to write the tasks down so finance sees the same job list you do. Deeper breakdown: Why Agencies Need Automated Performance Monitoring in 2026.

Compare labour savings to monitoring tool subscription cost

Use your vendor’s live pricing. For planning against Apogee Watcher tiers (verify on pricing before publishing client-facing numbers):

Portfolio shape	Illustrative plan band	Order of magnitude
Solo / few sites	lower tier	tens of € per month
Small team, ~10–25 sites	mid tier	tens to low hundreds
Agency portfolio, many sites	agency tier	low hundreds

Net monthly benefit ≈ (Hours saved × loaded_rate) − subscription
Payback months      ≈ subscription ÷ monthly net benefit   // if net > 0

Example (continuing 62 h saved at €75/h):

Labour value saved: 62 × €75 = €4,650/month
Subscription (illustrative agency tier): €199/month
Net: ~€4,451/month before you count faster reporting or fewer client escalations

Even at half the time savings, the subscription is usually smaller than one retained hour of a senior developer.

Copy-paste block: Worksheet B

// Agency operations ROI — [AGENCY NAME]
// Month: [YYYY-MM]

PORTFOLIO
Clients under performance watch     = [N]
Key pages per client (avg)          = [P]
Strategies (mobile/desktop)         = [D]
Test frequency per month per page   = [F]

MANUAL MODEL
Runs/month        = Clients * P * D * F
Run+file minutes  = [m]  // default 10
Run hours         = Runs * m / 60
Review hours      = Clients * 0.25 * 4    // 15 min/wk
Report hours      = Clients * 0.75        // 45 min/mo
Fire drill hours    = Clients * [hrs] * [incidents]
TOTAL MANUAL HOURS  = sum above

AUTOMATED MODEL
Review hours        = Clients * (5/60) * 4
Report hours        = Clients * (12/60)
Investigation hours = [your estimate]
TOTAL AUTO HOURS    = sum above

HOURS SAVED         = MANUAL - AUTO
Loaded rate         = [€/hour]
Monthly labour value = HOURS SAVED * Loaded rate
Subscription        = [€/month]
NET MONTHLY         = Monthly labour value - Subscription

DECISION NOTE
If NET > 2× subscription → automation is rational at this portfolio size.
If NET < 0 → stay manual longer OR reduce scope (fewer pages/strategies).

Performance monitoring ROI across a multi-client portfolio (Worksheet C)

When account leads ask “what is monitoring worth across all clients?”, sum Worksheet A per flagship client (do not blindly multiply one uplift across the whole book) and compare to one Worksheet B for your team.

Total annual client opportunity (scenario) = Sum of Worksheet A annual uplifts (top N clients)
Total annual agency labour value         = Worksheet B NET MONTHLY × 12

Keep client names on separate tabs. Procurement rarely wants one blended “we will make you €2M” figure without per-brand assumptions.

Performance monitoring ROI examples: e-commerce, B2B, and agency ops

E-commerce checkout: client revenue worksheet

Input	Value
`S`	80,000 sessions/month on mobile checkout
`CR`	1.8%
`AOV`	€62
`L`	1% (conservative)

Monthly revenue ≈ 80,000 × 0.018 × €62 = €89,280
Annual uplift at 1% ≈ €10,714

Pitch line: “A one-point conversion improvement on checkout pays for a year of monitoring many times over; our job is to keep you in the ‘good’ band after every release.”

Pair with Performance monitoring for e-commerce: what metrics matter most for which URLs to watch.

B2B lead gen: client worksheet with first-party data

No strong public L? Use the client’s funnel:

4,000 sessions/month on /demo
3.2% meeting booked
€12,000 average contract value (directional)
Segment in analytics: meetings booked when LCP p75 > 3s vs ≤ 2.5s → observed 0.4 pp difference (example only)

Convert 0.4 pp to L only if the sample is stable month to month. If not, stay at 0.5% in the worksheet and propose a 90-day measurement retainer.

Agency operations: 12 clients, internal worksheet B

Assumption	Value
Clients	12
Pages	3
Strategies	2
Frequency	4×/month
Manual minutes/run	10
Loaded rate	€70/h
Subscription	€199/month (verify live pricing)

Manual run hours alone: 12×3×2×4 = 288 runs → 48 h
Add review + reports + one fire-drill block ≈ 27 h → ~75 h total
Automated total ≈ 13 h → 62 h saved
Labour value ≈ €4,340; net after subscription ≈ €4,141/month

That is the slide for your ops lead, not “the tool is €199”.

How to present performance monitoring ROI to clients (without spreadsheet noise)

What to show client stakeholders

Lead with one journey and one scenario (L labelled “conservative”).
Show monitoring as insurance on that number: budgets, scheduled tests, alerts. How to sell performance monitoring services to your clients covers the conversation; alerts and digests is what turns thresholds into something the team actually acts on.
Offer a monthly rhythm: Monthly performance review template for agency teams.

What to keep internal (finance and delivery)

Compare hours, not licence fees alone.
Name who stops doing manual exports (role + name in the project plan).
If net ROI is thin, shrink scope (fewer URLs, weekly not daily) before dropping monitoring entirely.

How to price performance monitoring retainers from your ROI model

Monitoring ROI on the client side justifies your retainer; ops ROI justifies the tool.

Service line	Typical client price band	Tool cost coverage
Monitoring only	€50–150/site/month	Often one small client covers the subscription
Monitoring + fixes	€200–500/site/month	Labour value dominates; tool is a line item
Premium (strategy + QBR)	€500+/site/month	Reporting templates and history are the product

If you productise monitoring, reuse Worksheet A in proposals and Worksheet B in your margin model. Scaling a digital agency without headcount covers the wider ops story.

When is performance monitoring not worth buying yet?

Automation is a poor buy if:

You monitor one or two sites with stable releases (manual + PSI may suffice).
You cannot maintain a URL list (automation without ownership rots).
Leadership will not act on alerts (ROI dies in unread inboxes; fix Slack alert policy template or email equivalent first).

If those do not apply and Worksheet B shows tens of hours saved, the next step is a pilot: five production URLs, four weeks of scheduled tests, one monthly review. How to set up automated PageSpeed monitoring for multiple sites walks through setup; the web performance monitoring for agencies page maps which product pieces matter for multi-client portfolios.

FAQ

How do you calculate performance monitoring ROI?

Use Worksheet A for client revenue upside (sessions × conversion rate × deal value × scenario lift) and Worksheet B for agency labour saved minus tool subscription. The copy-paste blocks above are the full model.

Should we show clients the full Worksheet B (our internal hours)?

No. Clients get Worksheet A (their upside) and the delivery plan. Keep internal labour maths in your margin discussion.

What if the client disputes the conversion lift percentage?

Agree on a measurement period: hold L at 0.5–1% for the proposal, commit to revisiting with their analytics after 90 days. Cite published research only as context, not as a contract guarantee.

Does this replace RUM or analytics?

No. It frames decisions. Field data (CrUX, analytics segments) should refine S, CR, and whether L is credible. Lab monitoring from tools like Apogee Watcher explains why metrics moved after deploys.

How does monitoring ROI relate to SEO ROI?

Separate slides. SEO upside is traffic and visibility; this worksheet is conversion on existing traffic. You can add a footnote linking to How Core Web Vitals impact SEO rankings without blending models.

We already use Li

Monthly Performance Review Template for Agency Teams

Tue, 28 Apr 2026 11:32:25 +0000

Most agency teams do not struggle with data. They struggle with rhythm.

You already have scores, alerts, and test history. The friction starts when the month ends and you need to answer four questions quickly:

What improved?
What regressed?
What matters for the client right now?
Who is doing what next?

This template gives you a repeatable monthly review in 30-45 minutes per client—built for multi-site teams where consistency beats perfect slides.

If you need setup guidance before review cadence, use How to Set Up Automated PageSpeed Monitoring for Multiple Sites. If you need a client-facing deliverable, pair this with Client-Ready Core Web Vitals Report Outline.

What we mean by a monthly performance review

Many “monthly performance review” templates are built for HR one-to-ones. This one is for website performance: Core Web Vitals, regressions, and the work your team ships—so clients who pay for speed and stability get a steady rhythm instead of one-off updates when something breaks.

You need: a clear agenda, a small set of metrics you can defend, copy that works in a client email, and three actions with owners—not “we will keep an eye on it”. The script below is that meeting. Run it internally first; the next section covers the client conversation.

Use this template as a meeting script

The structure below works as:

an internal monthly review meeting
a client-facing performance call
a handover note between technical and account teams

Copy this into your docs tool and reuse it every month.

// Monthly Performance Review — [CLIENT / SITE]
// Period: [YYYY-MM]
// Meeting date: [DATE]
// Owner: [NAME]
// Participants: [NAMES]

1) Snapshot
- Overall status: [Healthy / Needs attention / Critical]
- Portfolio summary:
  - Sites monitored: [N]
  - Pages monitored: [N]
  - Tests run this month: [N]
  - Alerts triggered: [N]
  - Alerts resolved: [N]

2) Metric trend review (mobile + desktop)
- LCP: [value] (last month: [value], delta: [value])
- INP: [value] (last month: [value], delta: [value])
- CLS: [value] (last month: [value], delta: [value])
- Performance score: [value] (last month: [value], delta: [value])
- Comment: [What changed and why]

3) Biggest wins this month
- Win #1: [change made] -> [metric impact] -> [business impact]
- Win #2: [change made] -> [metric impact] -> [business impact]

4) Regressions and risks
- Regression #1: [page / template]
  - Detected: [date]
  - Suspected cause: [release, script, image, third-party, etc.]
  - Current impact: [SEO / UX / conversion]
  - Severity: [High / Medium / Low]
- Regression #2: [...]

5) Top 3 actions for next month
- Action 1: [task]
  - Owner: [name]
  - Due: [date]
  - Success metric: [target]
- Action 2: [...]
- Action 3: [...]

6) Decisions and dependencies
- Client decisions needed: [yes/no + details]
- Cross-team dependencies: [dev, content, design, hosting]
- Blockers: [list]

7) Client communication summary
- What we will tell the client this month (3 bullets max)
- Confidence level: [High / Medium / Low]
- Escalation needed: [yes/no]

Internal review first, then the client

Do not skip the internal pass. Half-explained metrics on a client call usually mean the team argues about interpretation in front of them—or nobody agreed what “green” meant before you dialled in.

Run sections 1–6 with tech plus account or delivery (15–20 minutes). Align on severity, strip noise, agree what you can say externally. Then use section 7 plus one executive line for the client call or email (20–30 minutes; account-only is fine for low-touch clients). Clients rarely need every alert ID—they need proof you are in control and a clear ask when their content, scripts, or hosting blocks progress.

On maintenance and monitoring retainers, this meeting is often the clearest proof of value. Still complete section 3 (wins). Stability after a heavy release month is a win worth naming.

Why this format works for agencies

It forces one pass from raw metrics to accountable actions.

Many reviews fail because teams stay in reporting mode: charts and discussion, then no owner. This template keeps one output in view: actions with names and deadlines. Keep budget targets visible in the room. If thresholds are still loose, set them with Performance Budget Thresholds Template before the next cycle.

A practical scoring model for monthly status

Use a simple status system so everyone speaks the same language:

Healthy: no high-severity regressions open; core templates stay within agreed thresholds
Needs attention: one or more key templates out of threshold, but impact is contained
Critical: high-impact regressions on revenue or lead pages, unresolved for multiple runs

Keep the labels simple. The goal is faster decisions, not a perfect classification scheme.

What to prepare before the meeting

Keep prep under 20 minutes per client:

Pull this month versus last month metric deltas
Export or copy the top alert events and resolution notes
Select the 2-3 most important pages (homepage, pricing, lead form, key product template)
Draft the three client-facing bullets in advance

Technical lead: confirm URLs, mobile and desktop, and budgets still match what you monitor. One line of suspected cause per regression; realistic effort for the top three actions.

Account or delivery lead: what the client already saw in tickets or Slack; promises in writing; whether section 7 reads like a service update, not a post-mortem.

If prep runs long, use the same export, comparison window, and three priority URLs every month.

After the meeting: outputs that close the loop

Tasks — three actions with owner and due date in your PM tool, not only in notes.
Client touchpoint — short email with section 7 bullets plus a dashboard or PDF link, or a call with the same content; depth should match the contract.
Threshold sanity — if the same template stays “Needs attention”, fix the budget, fix the page, or reset expectations in writing.

Optional: one line in your internal monthly business review—“Performance: [status] — top risk: [X]”—so web performance stays visible next to SEO and content.

Common mistakes this template avoids

1) Mixing diagnosis with decision-making

You can spend an hour debating why a metric moved and still leave without a plan. Keep root-cause deep dives separate when needed. The monthly review should end with owned actions.

2) Reporting averages only

Averaged scores hide broken high-value pages. Always include at least one section on key templates and business-critical URLs.

3) No link between performance and client impact

Clients do not buy "better Lighthouse numbers". They buy risk reduction, stability, and fewer surprises. Translate each major change into likely impact on user experience and search visibility.

4) Too many priorities

If every item is urgent, nothing is urgent. Keep the next-month action list to three items max.

Suggested monthly cadence

Week 1: run the review and lock actions. Weeks 2–3: ship fixes. Week 4: verify and draft next month’s notes. Busy sites can add weekly tactical checks; still hold one monthly reset.

If you are still deciding what to monitor, start with Core Web Vitals Monitoring Checklist for Agencies. If the same pages fail every month, read The Complete Guide to Performance Budgets for Web Teams and reset thresholds.

FAQ

How long should a monthly performance review meeting take?
30-45 minutes per client is enough if prep is done and the agenda is fixed. Longer meetings usually mean unclear ownership or too much ad-hoc debugging inside the call.

Who should attend from the agency side?
At minimum: one technical owner and one account owner. Technical owners explain causes and options; account owners align recommendations with client priorities and communication.

Is this the same as an HR performance review template?
No. This article is for website performance and delivery reviews with clients or internal delivery teams. It does not cover employee appraisals or performance improvement plans.

Should we include every monitored page in the review?
No. Review trends portfolio-wide, then focus discussion on business-critical templates and the highest-impact regressions.

What if nothing significant changed this month?
That is still a useful outcome. Record stability, confirm thresholds are still appropriate, and document one preventive action for next month.

How is this different from a client report template?
This template is for decision meetings. A client report is a polished output for stakeholders. Use this review first, then summarise outcomes in a client-ready report format.

What should I put in the calendar invite?
Title: “Monthly web performance review — [Client] — [Month YYYY]”. Body: link to the dashboard or report, four-bullet agenda (snapshot, trends, regressions, three actions), attendees.

Can we run this monthly review for a single site?
Yes—set section 1 counts to one site; the rest of the script stays the same.

Same agenda every month and every action owned—that is how monitoring reads as a service. Sign up for scheduled PageSpeed checks with less manual prep.

Site Audit Checklist: Onboarding a New Client for Performance Monitoring

Mon, 13 Apr 2026 09:10:11 +0000

Most onboarding checklists are either too light ("run a test and send a report") or too heavy (a long enterprise worksheet no one follows). Agency teams need something in between: a practical checklist you can run repeatedly, with enough structure to avoid blind spots.

This guide is built for teams onboarding client sites into ongoing performance monitoring. The goal is clear: move from "new client handover" to "monitoring is live, scoped, and actionable" without spending two weeks in setup mode.

If you need the monthly review workflow after onboarding, pair this with Monthly Performance Review Template for Agency Teams.

What teams usually need from a site audit checklist

Most teams need three things from an onboarding checklist:

A template they can copy directly.
A sequence of actions in the right order.
Clarity on what matters most in the first week.

This article covers all three. It starts with a copy/paste checklist, then explains how to use each section so your first monitoring cycle produces decisions, not just numbers.

Before you touch tools: lock scope and ownership

Do not begin with a full crawl and a 200-row spreadsheet. Start with agreement.

For each client, lock these five items first:

Primary domain and critical subdomains
Priority templates (homepage, lead form, pricing, service/product, checkout)
Mobile and desktop coverage
Reporting cadence (weekly internal, monthly client-facing)
Alert recipients and first-response owner

If you skip this step, the first client conversation usually becomes "why are these pages here?" instead of "what do we fix first?"

Site audit checklist (copy/paste template)

Use this in your docs tool, ticketing system, or onboarding runbook.

// Site Audit Checklist — Performance Monitoring Onboarding
    // Client: [NAME]
    // Domain(s): [DOMAIN]
    // Owner: [NAME]
    // Date: [YYYY-MM-DD]
    
    1) Access and context
    - [ ] Confirm primary domain + environments (prod/stage)
    - [ ] Confirm CMS / stack basics (WordPress, Shopify, custom, etc.)
    - [ ] Confirm deployment owner / technical contact
    - [ ] Confirm analytics and consent constraints
    
    2) URL inventory
    - [ ] Pull URLs from sitemap(s)
    - [ ] Add business-critical URLs manually (pricing, lead form, key landing pages)
    - [ ] Remove obvious noise pages (search params, utility pages, test paths)
    - [ ] Group pages by template type where possible
    
    3) Measurement setup
    - [ ] Enable mobile + desktop testing
    - [ ] Set test frequency by site priority
    - [ ] Confirm test quota and page limits match plan
    - [ ] Confirm data retention expectation (30/90/365 days or plan default)
    
    4) Baseline capture (first run)
    - [ ] Run initial tests for priority pages
    - [ ] Record baseline LCP / INP / CLS and performance score
    - [ ] Mark currently failing pages and highest-severity regressions
    - [ ] Note pages with no field data so expectations are clear
    
    5) Budgets and alerts
    - [ ] Set initial thresholds (LCP, INP, CLS) per site/template
    - [ ] Set alert channels (email / Slack / webhook where available)
    - [ ] Confirm cooldown and escalation owner
    - [ ] Confirm who receives alerts and who owns first response
    
    6) Reporting readiness
    - [ ] Decide client-facing summary format (call, email, PDF/report link)
    - [ ] Define monthly review owner and calendar slot
    - [ ] Draft first "what we monitor and why" note for client
    - [ ] Confirm next review date
    
    7) Handover
    - [ ] Create top 3 actions from baseline findings
    - [ ] Assign owner + due date for each action
    - [ ] Log blockers (hosting, scripts, release dependencies)
    - [ ] Share final onboarding summary internally

How to run each section without adding overhead

The checklist above is the scaffold. This section explains how to keep it efficient.

1) Access and context

This is where most onboarding delays begin. The most common blocker is not technical complexity; it is missing ownership.

Minimum acceptable output from this section:

one technical contact who can approve changes,
one business contact who can prioritise pages,
one statement on environment scope (production only, or production + staging).

If that is not settled, pause setup and resolve it before running baseline tests.

2) URL inventory

Start with sitemap URLs, then force-add business-critical pages. Sitemaps are useful, but they often miss campaign pages, dynamic pricing paths, or recently launched funnels.

A practical first pass for most sites:

1 homepage URL
2-5 conversion URLs (pricing, lead form, checkout, booking)
5-10 high-traffic content or service templates

That gives you enough coverage to catch meaningful regressions without drowning your team in low-value alerts.

3) Measurement setup

Always enable both mobile and desktop. Even if the client says "our users are mostly desktop", mobile regressions still affect search visibility and user experience on mixed traffic.

Set test cadence based on risk:

high-change sites: daily
medium-change sites: weekly
stable sites: weekly or monthly

Avoid a false precision setup where every site gets the same frequency. Match cadence to release behaviour and business risk.

4) Baseline capture

A baseline is not "export all scores". It is a snapshot you can compare against in four weeks.

For each priority page, record:

current LCP, INP, CLS
current performance score
current status (within threshold / out of threshold)
one likely cause if out of threshold
one likely business impact

That last two lines are what make the baseline usable in client calls.

5) Budgets and alerts

Budgets and alerts are where monitoring becomes operational.

Do not over-tune on day one. Set initial thresholds, then adjust after one month of data. The objective is a stable signal, not perfect thresholds in the first week.

When setting alert channels, define response paths explicitly:

who receives first alert,
who triages,
who communicates externally,
what counts as escalation.

Without this, alerts become noise and trust drops quickly.

6) Reporting readiness

If the client is onboarding, they need clarity more than polish.

First-cycle reporting should answer:

What we monitor.
What is currently failing.
What we will fix first.
What we need from you (if anything).

You can upgrade format later (dashboards, PDFs, branded summaries). Start with consistency.

7) Handover

A clean handover has only three mandatory outputs:

top three actions,
owner and due date for each action,
known blockers.

If you end onboarding without those, you have setup but not momentum.

Priority matrix for first-week triage

Use this quick matrix when multiple regressions appear at once:

Impact	Effort	Priority
High business impact	Low effort	Do first
High business impact	High effort	Plan this cycle
Low business impact	Low effort	Batch with other fixes
Low business impact	High effort	Backlog unless it trends worse

This keeps your first month focused on visible wins rather than interesting low-impact fixes.

Common onboarding mistakes and how to avoid them

Tracking too many pages too early

A long page list feels thorough, but it slows triage and increases alert fatigue. Start with the minimum meaningful set, then expand after your first review cycle.

No alert owner

Shared inbox alerts with no owner create silent regressions. Assign one response owner before the first scheduled run.

Baseline with no narrative

"LCP is 3.8s" alone is not useful. Pair every key metric with context:

page type,
suspected cause,
likely user/business impact.

That turns metrics into decisions.

Promise mismatch on reporting

Do not promise polished monthly packs before setup stabilises. First cycle should prioritise baseline clarity and top actions.

Mixing diagnosis with onboarding

Onboarding is not root-cause analysis on every issue. Capture the issue, assign severity, and create an action list. Deep diagnosis can run in delivery sprint time.

Suggested first-month cadence after onboarding

Use a straightforward rhythm:

Week 1: onboarding, baseline, first top-three action list
Week 2: ship highest-impact fixes
Week 3: verify against fresh runs
Week 4: run monthly review and reset priorities

If thresholds still feel loose, use Performance Budget Thresholds Template before your first full client review.

Example onboarding summary you can send to a client

Use this short format once setup is complete:

Subject: Performance monitoring onboarding complete — next steps
    
    We have completed onboarding for [DOMAIN].
    
    Monitoring scope:
    - [N] priority pages across [template groups]
    - Mobile and desktop tracking enabled
    - Baseline recorded for LCP, INP, CLS, and performance score
    
    Current status:
    - [X] pages within thresholds
    - [Y] pages needing attention
    - Top risk: [short description]
    
    Next three actions:
    1) [Action] — owner [name], due [date]
    2) [Action] — owner [name], due [date]
    3) [Action] — owner [name], due [date]

This is usually enough for the first cycle. You can move to a fuller monthly format once trends are visible.

FAQ

How many pages should we include in the first onboarding pass?
Usually 10-20 priority URLs is enough for a reliable baseline. Expand only after your team can keep up with triage.

Should we onboard mobile first or both mobile and desktop?
Both. One-device monitoring hides regressions and creates reporting gaps.

Do we need complete page-type classification before monitoring starts?
No. Start with practical buckets (homepage, conversion pages, core templates), then refine over time.

What if the client has no clear target thresholds yet?
Use pragmatic starter thresholds, mark them provisional, and revise after one month of observed data.

How long should onboarding take per client?
For typical brochure/ecommerce sites, setup and first baseline can usually be done in 30-90 minutes if ownership and access are clear.

What should we do if alerts spike in week one?
Check whether scope is too broad or thresholds are too strict. Triage by business impact and fix ownership before widening coverage.

A good site audit checklist does more than capture URLs and scores. It creates operating rhythm: clear scope, clear owners, and clear next actions. That is what makes monitoring useful after month one.

Client-Ready Core Web Vitals Report Outline

Thu, 09 Apr 2026 02:53:33 +0000

The Problem: Client Reports That Don't Land

You spend hours pulling numbers, screenshots, and notes into something you can send to a client — and they still don't get the story. A raw PageSpeed screenshot tells a developer everything but tells a client nothing. A "your site is fast" email tells them nothing useful either. The result: wasted time and clients who don't see the value of performance work.

The solution: A report structure that translates metrics into business language, shows trends, and recommends specific next steps. This template gives you that — an outline you can use in Notion, Google Docs, PDF, or any format your clients prefer.

The best client reports do three things:

Translate technical metrics into business language
Show trends, not just snapshots
Recommend specific next steps

Copy the outline below, brand it, and start delivering reports that build client confidence — without manual data assembly. For performance budget setup, see The Complete Guide to Performance Budgets; for a monitoring checklist, see Core Web Vitals Monitoring Checklist for Agencies.

The Report Template

Page 1: Executive Summary

// [AGENCY NAME] Performance Report
// Prepared for: [CLIENT NAME]

// Period: [START DATE] – [END DATE]

// Prepared by: [ACCOUNT MANAGER]

OVERALL STATUS: [HEALTHY / NEEDS ATTENTION / CRITICAL]
Key Highlights:
[1-3 bullet points summarizing the most important findings]

Example: "Homepage performance improved by 15% this month after

  image optimisation. Product pages remain stable. One new issue

  detected on the checkout page (layout shift) — fix in progress."

Sites Monitored: [NUMBER]

Pages Monitored: [NUMBER]

Tests Run This Period: [NUMBER]

Alerts Triggered: [NUMBER]

Alerts Resolved: [NUMBER]

Design notes: Keep this to one page. The executive summary should be scannable in 30 seconds. Use the status indicator (Healthy/Needs Attention/Critical) as a visual anchor — green/orange/red colour coding works well.

Page 2: Core Web Vitals Scorecard

For a full overview of what is Core Web Vitals, see our practical guide. The scorecard below summarises the key metrics for clients.

// Core Web Vitals Scorecard — [SITE DOMAIN]
                MOBILE                  DESKTOP

Metric Current Target Status Current Target Status
─────────────────────────────────────────────────────────────────
LCP [val]s 2.5s [OK/!] [val]s 2.0s [OK/!]
INP [val]ms 200ms [OK/!] [val]ms 150ms [OK/!]
CLS [val] 0.10 [OK/!] [val] 0.10 [OK/!]
Perf Score [val] 90 [OK/!] [val] 90 [OK/!]

Period Change:
LCP: [↑/↓/→] [change value] vs previous period
INP: [↑/↓/→] [change value] vs previous period
CLS: [↑/↓/→] [change value] vs previous period
Score: [↑/↓/→] [change value] vs previous period

Legend:
✓ Within target (Good)
! Needs attention (over target)
✗ Critical (significantly over target)

How to explain metrics to clients:

Metric	Client-Friendly Explanation
LCP	"How long it takes for the main content of your page to become visible. Think of it as the moment your page looks 'loaded' to a visitor."
INP	"How quickly your page responds when someone clicks a button, taps a link, or types in a form. Lower is better — it should feel instant."
CLS	"How much your page content jumps around while loading. A low score means your page stays stable. A high score means elements shift unexpectedly, which frustrates visitors."
Performance Score	"An overall grade from 0-100 based on Google's analysis. 90+ is good. Below 50 needs immediate attention."

Page 3: Page-by-Page Breakdown

// Page Performance Breakdown
Page            Mobile Score  Desktop Score  Status      Notes

────────────────────────────────────────────────────────────────

Homepage        [score]       [score]        [status]    [notes]

/pricing        [score]       [score]        [status]    [notes]

/contact        [score]       [score]        [status]    [notes]

/blog           [score]       [score]        [status]    [notes]

/products       [score]       [score]        [status]    [notes]

/checkout       [score]       [score]        [status]    [notes]
Top Performers:

  > [Page] — Score [X], consistently above target
Needs Attention:

  > [Page] — Score [X], LCP exceeds target by [Y]ms

  > [Page] — Score [X], CLS at [Y] (target: 0.10)

Page 4: Trend Analysis

// Performance Trends — Last [3/6/12] Months
[Include a simple line chart or sparkline showing score trends over time]
Month       Avg Mobile Score    Avg Desktop Score    Alerts

────────────────────────────────────────────────────────────

[Month 1]   [score]             [score]              [count]
[Month 2]   [score]             [score]              [count]
[Month 3]   [score]             [score]              [count]
Trend Summary:

  > Overall direction: [IMPROVING / STABLE / DECLINING]

  > Biggest improvement: [Page/Metric] improved by [X]

  > Area of concern: [Page/Metric] has declined [X]% over [period]

Why trends matter for clients: A snapshot tells them where they are. A trend tells them where they're heading. Clients appreciate knowing their investment in optimisation is paying off — or that a new issue needs attention before it gets worse.

Page 5: Issues and Actions

// Issues Detected This Period
RESOLVED ISSUES:

[Issue description — what was wrong]

Impact:   [How it affected the site]

Fix:      [What was done to resolve it]

Result:   [Improvement achieved — before/after metrics]

[Next resolved issue...]


OPEN ISSUES:

[Issue description]

Impact:   [Business impact in plain language]

Priority: [High / Medium / Low]

Plan:     [What will be done and when]

ETA:      [Expected resolution date]

[Next open issue...]


NO ISSUES DETECTED:

  [If everything is within budget, state that clearly]

  "All monitored pages are performing within target thresholds.

   No issues were detected during this reporting period."

Page 6: Recommendations

// Recommendations for Next Period
PRIORITY ACTIONS:

[Specific, actionable recommendation]

Expected Impact: [What improvement to expect]

Effort:          [Low / Medium / High]

Timeline:        [When it should be done]

[Next recommendation...]


OPTIMIZATION OPPORTUNITIES:

  > [Optional improvements that could further boost performance]

  > [These aren't urgent but would provide incremental gains]
UPCOMING CONSIDERATIONS:

  > [Any upcoming changes that could affect performance]

  > Examples: planned redesign, new feature launch, holiday traffic

Page 7: Appendix (Optional)

// Technical Details (for clients who want the raw data)
Test Configuration:

  Tool:           Apogee Watcher (PageSpeed Insights API v5)

  Test Frequency: [Daily / Weekly]

  Strategies:     Mobile + Desktop

  Pages Monitored: [List of URLs]
Budget Configuration:

  LCP:   ≤ [value] (mobile) / ≤ [value] (desktop)

  INP:   ≤ [value] (mobile) / ≤ [value] (desktop)

  CLS:   ≤ [value] (mobile) / ≤ [value] (desktop)

  Score: ≥ [value] (mobile) / ≥ [value] (desktop)
Raw Data:

  [Link to full test results in monitoring dashboard]

  [Or: "Available upon request"]

Report Delivery Guide

Frequency Options

Frequency	Best For	Content Depth
Weekly	Active optimisation projects, post-launch monitoring	Scorecard + issues only (2 pages)
Monthly	Standard retainer clients	Full report (all sections, 5-7 pages)
Quarterly	Strategic review clients, low-change sites	Full report + trend analysis + strategy recommendations

Delivery Format

Format	Pros	Cons
PDF	Professional, branded, shareable	Static, not interactive
Notion	Interactive, easy to update	Requires client Notion access
Google Docs	Collaborative, easy to share	Less polished visually
Email Summary	Low-friction, quick to consume	Limited depth
Dashboard Link	Real-time, always current	Client must log in

Recommended approach: Send a 2-3 paragraph email summary with the key highlights, attach the full PDF report, and include a link to the live dashboard for clients who want to explore further.

Email Template for Report Delivery

Subject: [CLIENT NAME] — Monthly Performance Report ([MONTH YEAR])
Hi [CLIENT NAME],
Here's your monthly performance report for [DOMAIN].
Quick summary:

Overall status: [HEALTHY / NEEDS ATTENTION]
Average mobile performance score: [SCORE] ([↑/↓] [CHANGE] vs last month)
[1 key highlight or achievement]
[1 item to note, if applicable]

The full report is attached. [If applicable: We've also included
recommendations for [SPECIFIC AREA] that could improve [SPECIFIC METRIC].]
Let me know if you'd like to discuss any of the findings.
Best,

[YOUR NAME]
[AGENCY NAME]

Customization Tips

When All Metrics Are Red

If every metric is over budget, don't bury the lead. In the executive summary, state clearly: "Performance needs immediate attention. All Core Web Vitals are currently over target." Then prioritise: list the single biggest issue (usually LCP or overall score) and the one fix that would have the most impact. Avoid overwhelming the client with a long list — give them one clear next step. Offer a call to discuss a remediation plan.

For Non-Technical Clients

Remove the appendix section entirely
Use the client-friendly metric explanations (from Page 2)
Focus on the "so what?" — not what the numbers are, but what they mean for the business
Replace metric names with plain language: "loading speed" instead of "LCP"

For Technical Clients

Include the appendix with raw data
Add Lighthouse audit screenshots for context
Reference specific recommendations from PageSpeed Insights diagnostics
Include code-level suggestions for fixes

For Enterprise Clients

Add a "Compliance" section showing SLA adherence
Include uptime and availability alongside performance
Add year-over-year comparisons
Include competitive benchmarking if data is available

Generating Reports Automatically

Building these reports manually for every client every month doesn't scale. The checklist:

[ ] Use a monitoring tool that stores historical test data
[ ] Export or pull data via API for each client
[ ] Automate the scorecard section (current values, status, trends)
[ ] Manually write the executive summary, issues, and recommendations (this is where your expertise adds value)
[ ] Generate the PDF with your agency branding

Apogee Watcher is building automated report generation with white-label branding — so the data assembly is handled automatically and you focus on the analysis and recommendations.

FAQ

How often should I send performance reports to clients?Weekly for active optimisation projects or post-launch monitoring. Monthly for standard retainer clients. Quarterly for strategic reviews or low-change sites. Match frequency to client expectations and how often performance changes.

What format works best for client reports?Most agencies send a 2–3 paragraph email summary with key highlights, attach a full PDF report, and include a link to the live dashboard. PDF is professional and shareable; the dashboard gives clients real-time access when they want it.

How do I explain Core Web Vitals to non-technical clients?Use client-friendly language: LCP = "how long until the main content is visible"; INP = "how fast the page responds when you click"; CLS = "how much the page jumps around while loading"; Performance Score = "an overall grade from 0–100." Focus on the business impact — SEO, conversion, user experience.

Should I include raw PageSpeed data or just the summary?For non-technical clients, stick to the scorecard, trends, and recommendations. Add an optional appendix with raw data for technical clients who want it. Never lead with raw data — lead with status (Healthy/Needs Attention) and key highlights.

What you can achieve: You can send client-ready CWV reports without spending hours in spreadsheets — status, scorecard, trends, and next steps in one place. Reports that reinforce your expertise and give clients a clear picture of where they stand.

Want to automate client performance reports with your agency branding? Apogee Watcher is building automated report generation so you can focus on insights, not data assembly. Join the waitlist for early access.

Slack Alert Policy Template for Web Performance Teams

Wed, 08 Apr 2026 09:51:34 +0000

The Problem: Alerts Without a Policy Are Chaos

You've got performance alerts, but nobody knows when to treat one as critical versus "review when you can." You either drown in notifications and start ignoring them, or you set thresholds so high that real issues slip through. Without a policy, your team doesn't know when to drop everything, when to acknowledge in the next standup, or how to avoid re-alerting on the same issue every hour.

The solution: An alert policy. It defines:

What triggers an alert
When the alert fires (thresholds and conditions)
Where the alert goes (channels, recipients)
How the team responds (severity levels, SLAs, escalation)

This template gives you a complete policy you can adopt, adapt, and paste into your team's Slack workspace or documentation. For background on what is Core Web Vitals (LCP, INP, CLS), see our practical guide; for performance budget thresholds and severity criteria, see The Complete Guide to Performance Budgets and our Performance Budget Thresholds Template.

The Alert Policy Template

Section 1: Alert Channels

Define where alerts are routed based on severity.

// Alert Channel Configuration
perf-alerts-critical
  Purpose:     P1 and P2 alerts only

  Who watches:  On-call engineer, tech lead

  Expectation:  Respond within 30 minutes during business hours

  Muted:        Never
perf-alerts
  Purpose:     All performance alerts (P1-P4)

  Who watches:  Full engineering team

  Expectation:  Review during next standup

  Muted:        Allowed outside business hours
client-[name]-alerts (per-client channels, optional)
  Purpose:     Client-specific performance alerts

  Who watches:  Account manager, assigned developer

  Expectation:  Review same business day

  Muted:        Allowed outside business hours
Email (fallback)

  Purpose:     Backup delivery for all P1 alerts

  Recipients:  Emails are not allowed, Emails are not allowed

  Expectation:  Ensures delivery if Slack is down

Section 2: Severity Levels

Define four severity levels based on metric deviation from budget. The "Poor" thresholds below match Google's Core Web Vitals definitions (LCP > 4s, INP > 500ms, CLS > 0.25).

// Severity Levels
P1 — CRITICAL

  Condition:   Any Core Web Vital in "Poor" range OR Performance Score < 50

  Thresholds:
- LCP > 4.0 seconds
- INP > 500 milliseconds
- CLS > 0.25
- Performance Score < 50

Channel: #perf-alerts-critical + email fallback
Response: Acknowledge within 30 minutes. Begin investigation immediately.
Escalation: If unacknowledged after 1 hour → notify tech lead directly
Cooldown: 4 hours (don't re-alert for same page/metric within 4 hours)

P2 — WARNING
Condition: Any Core Web Vital exceeds budget by > 20% but not in "Poor" range
Thresholds:

- LCP > 3.0 seconds (budget: 2.5s, 20% over)
- INP > 240 milliseconds (budget: 200ms, 20% over)
- CLS > 0.12 (budget: 0.1, 20% over)
- Performance Score < 75

Channel: #perf-alerts-critical
Response: Investigate within 4 hours during business hours.
Escalation: If unresolved after 24 hours → escalate to P1
Cooldown: 8 hours

P3 — NOTICE
Condition: Any Core Web Vital exceeds budget but by < 20%
Thresholds:

- LCP 2.5 – 3.0 seconds
- INP 200 – 240 milliseconds
- CLS 0.10 – 0.12
- Performance Score 75 – 89

Channel: #perf-alerts
Response: Review in next standup. Create ticket if persistent.
Escalation: If still over budget after 3 consecutive tests → escalate to P2
Cooldown: 24 hours

P4 — INFO
Condition: Score improved significantly OR metric returned to budget after violation
Thresholds:

- Performance Score improved by > 10 points
- Previously violated metric now within budget

Channel: #perf-alerts
Response: No action required. For awareness only.
Cooldown: None (fire once per event)

Section 3: What to Include in Each Alert

Define the content of each alert message so the team can triage quickly.

// Alert Message Template
[SEVERITY] Performance Alert — [SITE] — [PAGE]
Metric:        [METRIC_NAME]

Current Value: [ACTUAL_VALUE]

Budget:        [BUDGET_VALUE]

Strategy:      [MOBILE / DESKTOP]

Deviation:     [PERCENTAGE OVER BUDGET]
Page URL:      [FULL_URL]

Test Time:     [TIMESTAMP]

Dashboard:     [LINK_TO_MONITORING_DASHBOARD]
Previous Test: [PREVIOUS_VALUE] at [PREVIOUS_TIMESTAMP]

Trend:         [IMPROVING / DEGRADING / STABLE]

Example P2 Alert:

[P2] Performance Alert — acme.com — Homepage
Metric:        LCP (Largest Contentful Paint)

Current Value: 3,200 ms

Budget:        2,500 ms

Strategy:      Mobile

Deviation:     28% over budget
Page URL:      https://acme.com/

Test Time:     2026-02-12 07:00 UTC

Dashboard:     https://app.apogeewatcher.com/sites/acme/results
Previous Test: 2,400 ms at 2026-02-11 07:00 UTC

Trend:         DEGRADING (↑ 800ms in 24 hours)

Section 4: Response Procedures

Define what happens after an alert fires.

// Response Procedure
Step 1: ACKNOWLEDGE

React to the Slack message to signal you're looking (e.g. add a reaction)
If P1: reply in thread confirming you're investigating

Step 2: TRIAGE

Open the monitoring dashboard link from the alert
Check if the issue is on multiple pages or isolated to one
Check if the issue is on mobile only, desktop only, or both
Check the trend: is this a sudden drop or gradual degradation?

Step 3: IDENTIFY CAUSE

Recent deployment? Check git log for changes in the last 24 hours
New third-party script? Check the page source for new external resources
Server issue? Check TTFB and server response times
Image/media change? Check if the LCP element changed
CDN issue? Check CDN provider status page

Step 4: FIX OR ESCALATE

If the fix is straightforward (e.g., revert a deployment, remove a script):
Fix it, then re-run a manual test to verify


If the fix requires investigation:
Create a ticket with the alert details
Set priority based on severity level
Assign to the appropriate developer



Step 5: VERIFY

After fixing, run a PageSpeed test to confirm the metric is back within budget
Reply in the alert thread with the resolution
React to the alert to signal resolution (e.g. checkmark reaction)

Step 6: POST-MORTEM (P1 only)

For P1 incidents lasting > 2 hours:
Write a brief post-mortem (what happened, why, how it was fixed)
Identify preventive measures
Share in #perf-alerts for team awareness

Section 5: Cooldown and De-Duplication Rules

Prevent alert fatigue with smart cooldown rules. PagerDuty's guide to reducing alert noise covers similar principles: rate limits, deduplication, severity-based routing, and suppression during maintenance. The rules below follow the same approach.

// Cooldown Rules



Rule 1: Per-Page Cooldown

  After an alert fires for a specific page + metric + strategy,

  do not fire again for the same combination within the cooldown period.
  P1: 4 hours

  P2: 8 hours

  P3: 24 hours
Rule 2: Escalation Override

  If a metric worsens during the cooldown period (e.g., P3 → P2 threshold),

  fire a new alert at the higher severity regardless of cooldown.
Rule 3: Resolution Resets Cooldown

  When a metric returns to within budget, the cooldown resets.

  If it exceeds budget again, a new alert fires immediately.
Rule 4: Maintenance Windows

  During scheduled maintenance or deployments:

Suppress P3 and P4 alerts for 2 hours
P1 and P2 alerts are NEVER suppressed
Use Slack's /mute-perf-alerts command (if configured) or

temporarily disable non-critical alerts in the monitoring tool

Section 6: Scheduled Reporting (Non-Alert)

In addition to reactive alerts, set up proactive scheduled messages.

// Scheduled Reports

Daily Digest (posted to #perf-alerts at 9:00 AM)

  Content:
- Number of tests run in the last 24 hours
- Number of budget violations detected
- Top 3 worst-performing pages (by score)
- Any new alerts that fired overnight

Weekly Summary (posted to #perf-alerts every Monday at 9:00 AM)
Content:

- Week-over-week score trends for all monitored sites
- Pages that improved vs degraded
- Open alerts that haven't been resolved
- API usage summary

Monthly Report (posted to #perf-alerts first Monday of each month)
Content:

- Link to the full monthly performance report
- Top wins and regressions
- Budget compliance percentage per client
- Recommendations for the coming month

Quick Start: Minimal Policy

If you're not ready for the full policy, start with this:

One channel — #perf-alerts for all alerts
Two severity levels — Critical (score < 50 or any CWV in "Poor" range) and Notice (everything else)
Cooldown — 8 hours minimum between alerts for the same page/metric
Response — Acknowledge Critical within 4 hours; review Notice in next standup

Expand to the full policy as your team and client count grow.

Customisation Guide

For Small Teams (1-3 People)

Simplify to two channels:

#perf-alerts for all alerts
Email fallback for P1 only

Reduce severity levels to P1 (Critical) and P3 (Notice). Skip P2 and P4.

For Large Agencies (10+ Clients)

Add per-client channels (#client-acme-alerts) and route alerts based on client assignment. Use a rotation for on-call acknowledgment. Consider integrating with PagerDuty or Opsgenie for P1 escalation.

For In-House Teams

Replace "client" language with "product" or "team." Route alerts to the team that owns the page or feature. Add deployment-triggered alerts (test automatically after every deploy).

Implementation Checklist

[ ] Create Slack channels (#perf-alerts-critical, #perf-alerts)
[ ] Configure monitoring tool to send alerts to the appropriate channels
[ ] Set up severity thresholds per the template above
[ ] Configure cooldown periods
[ ] Document the response procedure in your team wiki
[ ] Brief the team on the new alert policy
[ ] Run a test alert to verify routing works
[ ] Schedule a 2-week review to adjust thresholds based on alert volume

FAQ

What's the difference between P1, P2, P3, and P4 severity levels?P1 is critical: any Core Web Vital in "Poor" range or Performance Score below 50. P2 is warning: metrics exceed budget by more than 20%. P3 is notice: metrics exceed budget but by less than 20%. P4 is informational: score improved or a previously violated metric returned to budget.

How do I prevent alert fatigue?Use cooldowns so the same page/metric doesn't alert repeatedly within a short window. Start with 8–24 hour cooldowns. Escalate only when metrics worsen or persist. Consider alerting only after 2+ consecutive tests over budget to filter natural fluctuation. PagerDuty's reduce-noise guide applies the same logic to incident management: deduplication, severity-based routing, and suppression during maintenance.

Should every team member get every alert?No. Route P1 and P2 to a small critical channel (on-call engineer, tech lead). Route all alerts to a general channel for visibility. Use per-client channels for agencies so the right account manager sees the right alerts.

Can I integrate performance alerts with PagerDuty or Opsgenie?Yes. Many monitoring tools support webhooks. Configure a webhook to fire on P1 alerts and point it at your incident management service. PagerDuty and Opsgenie accept incoming webhooks for alert creation.

How often should I review and adjust alert thresholds?Plan a review every 2–4 weeks for the first few months. If you're getting too many P2 or P3 alerts, thresholds may be too tight (or you have real regressions to fix). If you rarely see alerts, thresholds may be too loose. Use the scheduled digest to spot patterns before changing numbers.

Should I use different thresholds for mobile vs desktop?Yes, if you test both. Mobile typically performs worse (slower networks, weaker devices). Many teams set the same budget for both but expect more mobile alerts; others set a slightly looser mobile budget (e.g. LCP 3.0s mobile vs 2.5s desktop). Document your choice in the policy so the team knows what to expect.

What you can achieve: Your team has one policy — who gets which alerts, how to respond, and how to avoid fatigue. You can add Slack (or email) alerts without chaos: everyone knows when to act and when to review later.

Apogee Watcher supports email alerts today, with Slack and webhook delivery coming soon. Set configurable thresholds, cooldowns, and per-site budgets. Join the waitlist to be the first to set up automated performance alerts for your team.

Performance Budget Thresholds Template

Wed, 01 Apr 2026 11:36:01 +0000

The Problem: No Clear Definition of "Good"

Without concrete thresholds, you can't set performance budgets, explain pass/fail to clients, or know when to alert. "LCP should be good" isn't enough — you need numbers. This template gives you those numbers: ready-to-use thresholds by site type (e-commerce, agency client sites, content, SaaS, landing pages) so you can define "good" once and enforce it everywhere.

Benefits: One place for all your budget values, client-ready language, and clear escalation (warning vs critical).
What you get: Set budgets per site, get alerted only when it matters, and report to clients with confidence.

Your Ready-to-Use Performance Budget Template

Copy the thresholds below into a Google Sheet, CSV, or your monitoring tool. No theory — just the numbers, organised by site type and strategy.

If you want the "why" behind these numbers, read our Complete Guide to Performance Budgets first.

The Template

Universal Thresholds (Google's "Good" Baselines)

These are the starting points for any site. For an introduction to what is Core Web Vitals, see our practical guide; the numbers below follow Google's documented thresholds. Adjust based on your baseline: If your current scores are far from these targets, use them as stretch goals and set interim budgets at your current values. Tighten as you improve.

Note: For LCP, INP, FCP, TBT, Speed Index — lower is better. "Poor" = exceed the max. For Performance Score and CLS — higher is better (Score) / lower is better (CLS).

Budget Template by Site Type

E-Commerce

Agency Client Sites (Default)

Content / Blog Sites

SaaS / Web Applications

Landing Pages / Marketing Sites

How to Use This Template

Step 1: Choose Your Site Type

Pick the template that matches your site (or start with the "Agency Client Sites" default if you're not sure).

Step 2: Copy Into Your Tool

Google Sheets / CSV:Copy the CSV data above into a spreadsheet. Add columns for:

Current Mobile Score — Your latest test result
Current Desktop Score — Your latest test result
Status — Within Budget / Over Budget / Critical

Monitoring tool (like Apogee Watcher):Enter the Mobile Budget and Desktop Budget values as your performance budget thresholds per site.

Lighthouse CI config:Translate thresholds into your lighthouserc.json:

{
  "ci": {
    "assert": {
      "assertions": {
        "largest-contentful-paint": ["error", {"maxNumericValue": 2500}],
        "cumulative-layout-shift": ["error", {"maxNumericValue": 0.1}],
        "total-blocking-time": ["error", {"maxNumericValue": 200}],
        "first-contentful-paint": ["warn", {"maxNumericValue": 1800}],
        "categories:performance": ["error", {"minScore": 0.9}]
      }
    }
  }
}

Step 3: Baseline Your Sites

Run PageSpeed Insights on your key pages. Fill in the "Current" columns. Anything marked "Over Budget" is an immediate action item.

Step 4: Set Up Alerts

Configure your monitoring tool to alert you when any metric exceeds its budget. Without alerts, this template is just a document. With alerts, it's a safety net.

Multi-Client Tracking Spreadsheet

For agencies managing multiple clients, use this structure:

Color-code the Status column: green for OK, red for OVER. Review weekly.

Budget Escalation Levels

Not all budget violations are equal. Use escalation levels to prioritise response:

Adjusting Budgets Over Time

Budgets aren't permanent. Review quarterly:

Tighten when:

Your team consistently meets budgets with room to spare
Competitors are faster and you're losing rankings
Client expectations increase

Loosen when:

New required functionality legitimately impacts performance (e.g., adding a complex interactive feature)
A temporary campaign requires heavier scripts (set an expiration date for the loosened budget)

Never loosen because:

"We can't fix it right now" — that's a prioritisation issue, not a budget issue
"The score fluctuates" — that's normal variance, not a reason to move the goalposts

FAQ

Can I customise these thresholds for my specific site?Yes. The template provides baseline values. Adjust based on your current scores, site type, and competitive benchmarks. E-commerce and landing pages often need stricter LCP and CLS budgets; content sites can use the standard thresholds.

What's the difference between the "Agency Client Sites" and "E-Commerce" templates?Agency Client Sites use Google's standard "Good" thresholds as a default. E-Commerce is stricter — lower LCP (2s vs 2.5s), tighter INP (150ms vs 200ms), and stricter CLS (0.05 vs 0.1) because conversion-critical pages need to feel instant.

How do I use this template with a monitoring tool?Copy the budget values into your tool's configuration. Most tools let you set thresholds per metric, per site, and per strategy (mobile/desktop). Once set, the tool will run tests against these budgets and alert you when thresholds are exceeded.

Should I track all metrics or just LCP, INP, and CLS?LCP, INP, and CLS are the Core Web Vitals — track them first. FCP, TBT, and Speed Index add useful context. Performance Score is a useful composite. Start with CWV + Score; add others if you need deeper visibility.

What you can achieve: Every site can have clear pass/fail thresholds, alerts that fire only when metrics cross the line, and reports clients understand. Use this template so performance budgets stop being guesswork and start being something you can set, enforce, and show.

Managing performance budgets across multiple sites is easier with automation. Apogee Watcher lets you set budgets per site, get alerted when thresholds are exceeded, and track trends over time. Join the waitlist for early access.

Core Web Vitals Monitoring Checklist for Agencies

Tue, 24 Mar 2026 08:50:23 +0000

Why Agencies Need a Systematic Approach

If you run an agency managing 10, 25, or 50+ client sites, you can't afford ad-hoc performance monitoring. One missed regression can cost you a client. One undetected CLS issue can silently tank a client's rankings for weeks before anyone notices.

This checklist gives you a repeatable system. Use it for onboarding new clients, for weekly monitoring routines, and as a quality assurance checkpoint before and after major deployments. For metric fundamentals, see What Are Core Web Vitals?; for budget thresholds, see our performance budget and template resources.

The Checklist

Phase 1: Client Onboarding

Run these checks when you first take on a new client's site.

[ ] Baseline all key pages — Run PageSpeed Insights (mobile + desktop) on the homepage, top 5 landing pages, and any high-conversion pages (pricing, contact, checkout)

[ ] Record baseline scores — Document current LCP, INP, CLS, FCP, TBT, and overall Performance Score for each page

[ ] Check field data availability — Verify whether the site has enough traffic for Chrome User Experience Report (CrUX) field data. If not, lab data will be your primary source

[ ] Identify the LCP element on each key page — Is it an image? A text block? A video? Knowing this tells you where to focus optimization

[ ] Audit third-party scripts — List all third-party scripts (analytics, chat widgets, ads, tracking pixels). Note which ones are render-blocking

[ ] Check image optimization — Are images served in modern formats (WebP/AVIF)? Are dimensions set? Are they responsive?

[ ] Test on real devices — Lab tests on a fast laptop don't reflect mobile experience. Test on a mid-range Android device or use throttled DevTools

[ ] Set performance budgets — Based on baselines and "Good" thresholds, define target values for each metric:

    LCP: ≤ 2.5s (stretch: ≤ 1.8s)

    INP: ≤ 200ms (stretch: ≤ 100ms)

    CLS: ≤ 0.1 (stretch: ≤ 0.05)

    Performance Score: ≥ 90

[ ] Set up automated monitoring — Configure daily automated tests for all key pages (both mobile and desktop strategies). Tools like Apogee Watcher show both lab and field data in every test, so you get CrUX real-user metrics alongside Lighthouse scores. If the client has no sitemap: Add key URLs manually; many tools support sitemap + manual URL entry.

[ ] Configure alerts — Set threshold-based alerts so you're notified when any metric crosses its budget

[ ] Document the monitoring setup — Record which pages are monitored, which budgets are set, and who receives alerts

Phase 2: Weekly Monitoring Routine

Run through this checklist every week for each client.

[ ] Review automated test results — Check the latest scores for all monitored pages. Look for any scores that have dropped since last week

[ ] Check for new alerts — Review any budget violation alerts that fired during the week

[ ] Verify resolved alerts — Confirm that previously flagged issues have been fixed and metrics are back within budget

[ ] Spot-check mobile scores — Mobile performance typically lags desktop. Pay extra attention to mobile LCP and INP

[ ] Review CLS for content-heavy pages — Pages with dynamic content, ads, or frequently updated elements are CLS hotspots

[ ] Check API usage — If you're on a quota-limited plan, verify you're not approaching your monthly test limit

[ ] Note any site changes — Were there any deployments, content updates, or plugin changes this week? Correlate with any score changes

[ ] Update the client if needed — Flag any significant regressions or improvements to the client

Phase 3: Monthly Deep Review

Once a month, go beyond the weekly checks.

[ ] Run full-site audit — Test all monitored pages, not just the key ones. Look for pages that may have degraded without triggering alerts

[ ] Compare month-over-month trends — Are scores improving, stable, or declining? Identify patterns

[ ] Review performance budget targets — Are your budgets still appropriate? Should they be tightened (stretch goals) or adjusted?

[ ] Audit new pages — Has the client added new landing pages, blog posts, or product pages? Add them to monitoring

[ ] Re-audit third-party scripts — New scripts get added all the time (marketing tags, A/B testing, chat widgets). Check for new render-blocking resources

[ ] Check Google Search Console CWV report — Compare field data trends with your lab monitoring data. Are they aligned?

[ ] Generate client performance report — Create a summary showing current scores, trends, issues fixed, and recommendations

[ ] Review and optimize alert configuration — Are you getting too many alerts (fatigue) or too few (blind spots)? Adjust thresholds and cooldowns

Phase 4: Pre-Deployment Checks

Run these before any major site change goes live.

[ ] Baseline current scores — Record current CWV metrics for all key pages before the deployment

[ ] Test staging environment — If available, run PageSpeed tests on the staging site to catch issues before production

[ ] Check for new render-blocking resources — Is the deployment adding new CSS/JS files? Are they deferred?

[ ] Verify image optimization — Any new images should be compressed, properly sized, and have dimensions set

[ ] Test critical interactions — For INP: test key interactions (form submissions, menu toggles, search) on the staging site

[ ] Plan post-deployment monitoring — Schedule immediate post-deploy tests to catch any regressions quickly

Phase 5: Post-Deployment Verification

Run within 24 hours of a deployment.

[ ] Run immediate tests — Test all key pages on both mobile and desktop within 1 hour of deployment

[ ] Compare against pre-deployment baseline — Look for any metric regressions

[ ] Check CLS specifically — Deployments often introduce layout shifts through new elements, changed styles, or updated fonts

[ ] Verify LCP element — Has the LCP element changed? A new hero section or image could alter LCP behavior

[ ] Monitor for 48 hours — Some issues only appear under real traffic. Keep monitoring closely for 2 days after deployment

[ ] Notify the client — Report on whether the deployment maintained, improved, or degraded performance

Red Flags: Escalate Immediately

Performance Score drops below 50 — Treat as an incident; something broke
LCP > 5 seconds — Users are seeing a blank page for too long; urgent
Multiple pages regress at once — Likely a site-wide change (deploy, new script, CDN issue)
Client reports "site feels slow" — Correlate with your data; if scores look fine, investigate server/network issues
Search Console shows sudden CWV degradation — Google has detected a problem; act fast

Per-Client Monitoring Setup Template

Use this template when setting up monitoring for a new client:

// Client Monitoring Setup
Client:          _______________
Domain:          _______________
Setup Date:      _______________
Account Manager: _______________

// Pages Monitored
Homepage:        [URL]
Landing Page 1:  [URL]
Landing Page 2:  [URL]
Product/Pricing: [URL]
Contact:         [URL]
Blog Index:      [URL]
[Custom]:        [URL]

// Performance Budgets
LCP Target:      _____ seconds (mobile) / _____ seconds (desktop)
INP Target:      _____ ms (mobile) / _____ ms (desktop)
CLS Target:      _____ (mobile) / _____ (desktop)
Score Target:    _____ (mobile) / _____ (desktop)

// Alert Configuration
Alert Recipients:    [emails/Slack channels]
Alert Cooldown:      _____ hours
Alert on:            [ ] LCP  [ ] INP  [ ] CLS  [ ] Score

// Testing Schedule
Frequency:       [ ] Daily  [ ] Twice daily  [ ] Weekly
Strategies:      [ ] Mobile  [ ] Desktop  [ ] Both

// Reporting
Report Frequency:    [ ] Weekly  [ ] Monthly
Report Recipients:   [emails]
Report Format:       [ ] PDF  [ ] Email summary

Scaling This Process

This checklist works for 5 clients or 50. The key is automation:

Automate testing so you're not running manual PageSpeed checks
Automate alerts so issues find you instead of you finding them
Automate reporting so client communication doesn't eat your week
Standardize budgets so every client gets the same quality of monitoring

The manual parts — investigating regressions, optimizing pages, communicating with clients — are where your expertise adds value. Everything else should be automated.

Tools like Apogee Watcher are built specifically for this workflow: multi-site monitoring with both lab and field data in every test, performance budgets, automated alerts, and client-ready reports from a single dashboard.

FAQ

How often should agencies run Core Web Vitals checks?At minimum: weekly spot-checks plus automated daily tests for key pages. For high-traffic or conversion-critical sites, run automated tests twice daily. Manual audits are recommended monthly or whenever major changes deploy.

What's the difference between lab data and field data for CWV monitoring?Lab data (Lighthouse, PageSpeed Insights) simulates a single test under controlled conditions. Field data (Chrome User Experience Report) reflects real users. Both matter — lab catches regressions before users see them; field confirms real-world experience. Use both.

When is manual PageSpeed testing enough vs automated monitoring?Manual testing is fine for 1–2 sites or occasional audits. Once you're managing 5+ client sites or running weekly checks, automation saves hours and catches issues immediately instead of when someone remembers to run a test.

Can I use this checklist with any performance monitoring tool?Yes. The checklist is tool-agnostic. Tools like Apogee Watcher, Lighthouse CI, or PageSpeed Insights can execute the tests; the checklist defines the process and what to check regardless of platform.

All Framer

Tue, 24 Mar 2026 04:57:59 +0000

What is All Framer?

AllFramer is a curated discovery hub for everything built around Framer. It organizes templates, components, plugins, tools, indie releases, and ecosystem resources into one structured and searchable place.

It is not a marketplace.
It does not sell products.
It helps you discover them faster.

Instead of searching across multiple creator websites, marketplaces, Twitter threads, Gumroad pages, and blogs, AllFramer brings everything together in one fast interface. Whether you're launching a SaaS product, portfolio, startup landing page, or eCommerce brand, our curated Framer resources help you find the best tool to design, prototype, and ship faster.

AllFramer is built for creators who want modern design, seamless animations, and production-ready assets in one place.

Features:

All Framer turns scattered discovery into structured exploration.

Blazing-fast search with powerful multi-filter discovery
Independent curated Official + Third-party + Indie resources
Filter resources by: Free or Pro, Category, Type of resource, Author, Style

Why Choose Framer for Your Projects?
Framer is a powerful no-code and low-code website builder that combines visual design freedom with production-ready performance. It's loved by startups, agencies, and creators who want pixel-perfect websites without complex development workflows.

With Framer, you get:

Visually built, production-ready websites
Built-in animations and interactions
Lightning-fast performance & SEO-ready structure
Responsive design out of the box
Easy CMS integration for dynamic content
Framer gives you the creative flexibility of a designer with the performance of a developer.

Submit your framer resource now!!

Django TemplateDoesNotExist Solved

Sat, 01 Jun 2024 23:24:56 +0000

While working in Django, you might encounter the "TemplateDoesNotExist" error. This issue typically arises due to incorrect configuration of template settings or paths. Fortunately, you can easily solve this error by properly configuring your settings.py file to include the correct template directories. In this article, I will guide you through the steps to set up your template directories correctly, how to debug potential issues, and ensure your templates are correctly recognized by Django a Python framework, all presented straightforwardly and practically.

Configuring Django Template Settings

The settings file of Django (settings.py) determines where the framework should look for templates. In this sense, it is the first step towards the successful resolution of all errors related to templates, since making sure that it is correctly set up is the first step.

Template Directories

Ensure your TEMPLATES configuration in settings.py includes the correct path to your templates. For example:

TEMPLATES = [
    {
        'BACKEND': 'django.template.backends.django.DjangoTemplates',
        'DIRS': [os.path.join(BASE_DIR, 'templates')],
        'APP_DIRS': True,
        ...
    },
]

Explanation: Inside the TEMPLATES setting, the value of the DIRS option should be the absolute path to the directory of your templates. BASE_DIR is a variable that holds the path to your project directory combined with 'templates' to point Django to the correct location.

Common Scenarios and Solutions

Scenario 1: Template Misplacement

Problem: Your template is not in a directory recognized by Django.

Solution: Move your template into one of the directories identified by the DIRS option in the TEMPLATES setting, or make sure the directory of your template appears in the appropriate application's templates directory if APP_DIRS is set to True.

Scenario 2: Typographical Errors in Template Name

Problem: There is a typo in the template name used in your view.

Solution: Verify the template name in your view matches exactly with the filename in your templates directory, including case sensitivity.

Scenario 3: Incorrect App Structure

Problem: Django cannot find the template because the app structure does not conform to Django's expectations.

Solution: Ensure each app in your project contains a templates directory. Django looks for templates inside the templates directory of each installed app if APP_DIRS is True.

Demonstrating a Solution

Create a Django project and start an app with the command:

python manage.py startapp app

Create a templates folder in the app folder and inside that create a my_template.html. Your folder structure should look something like the following.

urls.py

from django.contrib import admin
from django.shortcuts import render
from django.urls import path

def sample_view(request):
    return render(request, "this_template_does_not_exist.html")

def my_view(request):
    return render(request, "app/my_template.html")

urlpatterns = [
    path("admin/", admin.site.urls),
    path("test/", sample_view, name="test"),
    path("view/", my_view, name="view"),
]

my_template.html

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Template</title>
</head>
<body>
    This template exists
</body>

Now start the server with

python manage.py runserver

Now when you go to http://localhost:8000/view you should be able to see the following output as the file exists and there are no typos involved.

But when you go to http://localhost:8000/test you should be able to see the following output as the file does not exist.

Caution: Confirm that `my_template.html` is placed in `/templates/` and that your `settings.py` correctly points to this directory as described earlier.

Best Practices to Avoid the "TemplateDoesNotExist" Issue

The TemplateDoesNotExist error is a common issue in Django that can halt your development process. However, it's also one of the easiest to prevent with the right practices. You can refer various Debugging Techniques in Python to know more about the type of error. Here are some tips to ensure you never run into this error again:

1. Verify Your TEMPLATES Configuration

The most common cause of this error is a misconfiguration in the TEMPLATES setting in your settings.py file. Double-check that you have correctly defined the DIRS list to include the paths to your templates. Use the os.path.join(BASE_DIR, 'templates') pattern to ensure that your paths are correctly constructed and platform-independent.

2. Adhere to Django's Project Structure

Django expects your project to follow a certain structure, with a specific place for templates. By default, Django looks for a templates directory in each app folder if APP_DIRS is set to True in your TEMPLATES configuration. Ensure you place your templates in the correct directories within your apps or in the global templates directory you specify in DIRS. You can also use a Virtual Environment to isolate the project.

3. Use Correct Template Naming and Referencing

Always verify that the template names and paths you use in your views match exactly with your template files, including case sensitivity, which can be an issue on some file systems. A common mistake is a simple typo in the template path or name, leading Django to report that it cannot find the template.

4. Understand Template Loading Mechanism

Familiarize yourself with how Django loads templates, especially when using multiple apps. Django will search through the apps listed in INSTALLED_APPS in the order they appear, looking for templates in each app's templates directory. Knowing this order can help you troubleshoot and understand which template is being loaded when you have templates with the same name in different apps.

5. Regularly Check for Deprecated or Moved Templates

When upgrading Django or third-party apps, templates might be deprecated or moved. Always check the release notes for any changes to template paths or names to ensure your project stays up-to-date and error-free.

6. Utilize Django's Template Debugging Tools

Make use of Django's built-in template debugging tools, such as setting DEBUG to True in your development settings to get detailed error pages that show you exactly where Django looked for your templates and where it failed to find them. This can be invaluable for quickly diagnosing and fixing path issues.

7. Consistent Use of Template Extensions

Be consistent in your use of template file extensions. Django does not enforce a specific extension for templates (.html is common but not required), but using different extensions inconsistently can lead to confusion and errors.

8. Automate Template Checks

Consider incorporating checks into your deployment pipeline that verify the existence of templates referenced in your views. This can be as simple as a script that scans your views for render calls and checks that the referenced templates exist in your project's template directories.

Conclusion

The "TemplateDoesNotExist" error in Django can be a stumbling block for developers. However, with a systematic approach to troubleshooting—verifying template locations, ensuring correct settings in settings.py, and checking for typos—you can resolve this issue efficiently. Understanding Django's templating system and how it locates templates is crucial for developing dynamic, error-free web applications.

Remember, the key to avoiding such errors lies in adhering to Django's project structure conventions and thoroughly checking your configuration settings. With these practices, you'll find working with Django templates to be a smooth and error-free experience.

Additional Resources

Django Official Documentation: Templates (https://docs.djangoproject.com/en/stable/topics/templates/)
Django Official Documentation: Settings (https://docs.djangoproject.com/en/stable/topics/settings/)