Notes

The monthly pass on a client site, and the letter that follows

27 October 2026

The monthly pass is the hour I actually spend. Not a dashboard tour, and not a plugin changelog pasted into an email. I open the site the way a stranger would, then I open the logins I am allowed to open, and then I write a letter a client can read without me on the call. If I skip the letter, the pass was for me. They are not paying for my private notes.

The blank shape of that letter is already a report template. How the lines should sound, so the retainer still makes sense later, is making the work visible. This note is the inspection: what I look at, in what order, and the sentence I keep when the finding is real. The uptime block inside the letter has its own page, the client website uptime report, because people keep trying to turn it into a monitoring product. It is a section.

Two outputs, one afternoon

I want two things on the desk when I stand up. A list I trust, which can be ugly, and a page they can forward. The list has dates, status codes, and the login I used. The page does not. If a finding cannot survive the translation, it does not go in the letter, and it might not have been a finding. “Plugin updated from 4.2.1 to 4.2.2” is a list item. It becomes a letter line only when I can say what the visitor gained, or when the honest line is “routine update, public site checked afterwards, no change they would notice.” That second sentence is allowed. Pretending every patch was a rescue is how the letter turns into advertising.

I block the pass on the same week each month, on the calendar, for each site. Not “when I remember.” A brochure site fits in about 90 minutes if nothing is on fire. I am not reporting an average I measured across a client base. I am telling you the block I put on the calendar. If the block runs out and the work is not done, the site needed a project, not a longer pass. I stop, write what I found, and quote the rest. Stretching the pass until midnight is how the next site’s letter gets skipped.

Before anyone logs in

I start with the roster row, not the homepage. The row has the public URL, the money path, who owns the registrar, the certificate expiry if I already stored it, the domain expiry, and the day this plan renews. If a date is blank, filling it is the first task of the pass. A blank date is not a clean bill of health. It is a hole.

Domain expiry and certificate expiry are different clocks. I wrote the operational version of that on the hosting stack note, including the published Let’s Encrypt dates and the ICANN redemption window. For the pass, the question is smaller. Is either date inside 30 days? If yes, it is a letter line and a task, not a footnote. ICANN’s registrant note on the Expired Registration Recovery Policy says registrars must send a notice about a month before a generic TLD expires and another about a week before. I do not wait for those emails. The client’s registrar mail often goes to an address nobody forwards. If I do not hold the login, I ask for the expiry date in the same monthly note, every month, until I have it.

Certificate lifetimes are shrinking on a published schedule, so “40 days left” will not mean the same thing in 2028 that it means now. Let’s Encrypt’s lifetime page, updated 22 July 2026, still shows a 90-day default. Their 7 October 2026 post moves the default to 64 days on 10 February 2027, and the December 2025 post puts 45 days on the classic profile on 16 February 2028. A warning at 30 days is comfortable on a 90-day certificate and late on a 45-day one. When you renew automatically, still read the date. Automation fails quietly, and the pass is the backstop.

The outside pass

No login. A browser that is not already authenticated. I want the site a stranger gets.

1. Homepage. It loads, the padlock is the real hostname, and HTTP sends me to HTTPS. I try the apex and the www host if both are in the wild. A broken redirect is the whole site for anyone who types the shorter name.
2. The money path. Contact, booking, checkout, donation, whichever one pays for the retainer. I submit a form only when I have a sink address that will not page a human. If I cannot submit safely, I confirm the form renders and I say so in the list, not in the letter as “tested the form” when I did not.
3. One interior page they care about. A menu, a product, a staff page. Homepages get the attention. Interior pages rot.
4. Certificate date and domain date, written down even if they match last month. Matching last month is the finding.
5. A quick look at the console only if something looks wrong. I am not on a bug hunt. I am confirming the page I can see is the page they think is live.

Uptime for the month, if you have a probe history, is a sentence: how the period looked, and any miss you are willing to show. I would rather show a bad Tuesday than hide it. The mechanics of that section are the uptime report. For the letter, one or two sentences. Not a chart dump.

Lighthouse, when I run it, is a snapshot, not a grade I promised. Chrome’s Lighthouse docs group the audits into performance, accessibility, best practices, and SEO. The performance score is a weighted blend of metrics, and Google’s scoring note says a good score is 90 to 100 and that a perfect 100 is not the goal. Accessibility audits are pass or fail. A page does not get partial credit because some buttons have names and some do not. I do not put four numbers in the letter unless a number moved for a reason I can see: a new third-party script, an image that became huge, a form field that lost its label. “Performance 81, was 84” is noise. “The homepage hero is now a video from a third party, and the first load got heavier. I can swap it for a still if you want” is a letter.

If you use a tool that already records this from the outside, read its output during the pass and then translate. RetainerProof’s digest is that outside record plus the work log, on one page, which is why the sample digest looks the way it does. The pass is still yours. The tool does not know that the phone number in the footer is last year’s.

The inside pass, only where you have a login

If you do not have a login, you do not invent an inside pass. You write “no admin access, outside checks only” in the list and you do not imply you updated anything. That sentence belongs in the letter when the plan is Watch. Pretending you looked in the back office is worse than the gap.

WordPress, when the plan includes it

Core, plugins, themes. I read the changelog of anything that is not a patch-level bump before I apply it, and I apply it on the cadence the plan named, not because a badge was red while I was in there. WordPress documents this split. Minor core updates, the maintenance and security releases, have auto-updated for a long time. Since 5.6, new installations also auto-update major releases unless a version-control checkout is detected. Existing sites stay on the old default, minor only, unless someone opted in. Know which one this site is. “WordPress updated itself” is a fine letter line when it is true. “I updated WordPress” is a different line, and I only write it when I did.

Then the things auto-update will not tell you. Users I do not recognise. An administrator named admin with an old address. Comments if the site still has them open. The backup plugin’s last success, and whether I have restored it this quarter. A green “backup completed” that I have never restored is a sticker. The hosting note has the restore drill. On a WordPress month I only confirm the latest job succeeded and that the off-site copy exists. I do not restore production into itself.

After updates, I load the homepage and the money path again. Logged out. An update that breaks the front is the whole pass, and the letter leads with the repair, not with the version numbers.

Webflow and Squarespace

There is no plugin list. The inside pass is: is the published site the site they think is published, are form notifications going to a person who still works there, is the site plan still the one that includes the features they use, and is custom code still the code you remember. Webflow’s help says custom code in head, body, and embeds is HTML, CSS, and JavaScript, not a server-side language, and each of those areas is capped at 50,000 characters. If a client pasted a large script, the cap and the “we will not troubleshoot this” policy are the risk, not a WordPress-style update. Squarespace’s help, updated 27 August 2026, says code injection is an advanced change outside their support, available on Core, Plus, Advanced, and some legacy plans. I check that the injection is still there and still the one I added. I do not “update Squarespace.” They do that. My line is about the form, the domain connection, or the code I am responsible for.

A custom app

The inside pass is the deploy log, the health URL, disk, and the backup drill’s last date. Dependency bumps that you actually shipped get a letter line in outcome form. “Checkout emails arrive again” above “the worker was using the old from-address,” if you want the second sentence at all. Error logs get a look for new patterns, not a paste into the letter. A stack trace is the list. The letter says whether the visitor was affected.

From the list to a sentence

I keep a translation on paper because I will otherwise drift back into my own dialect. The left side is what happened. The right side is what I am willing to send. These rows are patterns, not a client’s month.

The last row is the exception to “everything waits for the letter.” A login I do not recognise is a phone call the same day. The letter is the record afterwards, not the alarm. Alarms go to me. The uptime page is the same distinction for downtime mail: you get the red email, they get the month. If they ask what the gap cost, the page for calculating the cost of downtime uses their revenue, not a borrowed average.

What stays out of the letter

Version lists. Raw Lighthouse JSON. The admin URL. My runbook. A screenshot of an error they cannot act on. A joke about their old copy. Another agency’s name. The word “just.”

Also out: work they did not ask me to narrate in public. If the pass found a messy content choice, I ask them in a separate note whether they want it changed. I do not perform the critique in the monthly letter their board might read. The letter is a record of care, not a design review.

The shape of the page

Work first. Then the plain note that the site was watched. Then the dates. The same order every month, so they learn where to look.

Here is a full letter for a site I am inventing so you can see the length. It is not a client. The hours and the outage are not a result I measured. I am calling the studio Maple and Pine, and the month is March 2026, which is already over as I write this.

Maple and Pine
https://maple-and-pine.example
March 2026

Work this month
Replaced the homepage announcement. The spring hours are the ones on the site now.
Contact form submissions arrive again. They had been going to a mailbox nobody checks.

The site, watched
The homepage answered through the month, except for a 14-minute gap on 10 March. It recovered without a change from me.
Certificate renews on its own. Next date is 2 June 2026.
Domain expires 14 November 2026. Auto-renew is on at the registrar you own.

Not in this letter
No new pages. The menu PDF you mentioned is a separate quote if you still want it.

That is the whole page. A client can read it on a phone in a queue. If yours needs a scroll to reach the point, cut the list, not the first two lines. The template page has a longer copy-paste version if you want the headings already laid out, and the WordPress maintenance report shows the same sections beside a public sample. Use it. Do not add sections because a tool offered them.

A checklist you can run

Print this or keep it in the roster. Tick it. The letter is the last tick, not a separate project. The sheet you can hand the client is the website maintenance checklist.

• Roster row open. URL, money path, registrar owner, both expiry dates, plan name.
• Any date inside 30 days becomes a task today, and a line in the letter.
• Logged-out browser. Homepage, redirect, money path, one interior page.
• Form submitted only if the sink is safe. Otherwise write “not submitted” in the list.
• Uptime sentence drafted from the probe history, including a miss if there was one.
• Lighthouse or a performance look only for a change you can explain. Otherwise skip the numbers.
• Inside pass matches the plan. No pretend admin on a site you cannot enter.
• WordPress: updates you are responsible for, strange users, backup job succeeded, front end rechecked logged out.
• Hosted builder: published state, form recipient, custom code still yours, plan still fits.
• Custom app: health URL, last deploy, last restore drill date, disk not creeping.
• Translate. Drop anything that has no client sentence, except the call-now items.
• Letter sent the same day. Same link as last month if you have one.

When the letter exists, the price conversation has somewhere to stand. How that price got packaged is a separate note, how I price a care plan. The pass is what makes the package true. A package with no pass is a mood.

Sources

• Chrome, Lighthouse overview. Performance, accessibility, best practices, and SEO.
• Chrome, performance scoring. A good score is described as 90 to 100. A perfect 100 is not the aim.
• Chrome, accessibility scoring. Those audits are pass or fail. Partial credit is not how the score works.
• WordPress, upgrading. Minor core updates versus major updates, and the 5.6 default for new installs.
• Let’s Encrypt, certificate lifetimes. Updated 22 July 2026. Default still 90 days.
• Let’s Encrypt, 64-day certificates. 7 October 2026.
• Let’s Encrypt, from 90 to 45. 2 December 2025.
• ICANN, ERRP for registrants. Notices about a month before expiry and about a week before.
• Webflow, custom code in head and body. HTML, CSS, and JavaScript. 50,000 characters per area. No server-side languages.
• Squarespace, add custom code. Updated 27 August 2026. Code injection is outside their support, on listed plan tiers.