Chapter 12 of 14

Keeping It

Optimisation decays. Not gradually and gracefully — suddenly, on the Tuesday somebody ships a redesign. This chapter is about finding out on Tuesday rather than in November.

The problem

Everything you have fixed in eleven chapters lives in files that other people edit. A new CMS template drops the canonical tag. A marketing page is rebuilt in a JavaScript framework and the text disappears from the served HTML. Someone adds a Disallow while debugging a staging deploy and forgets to remove it.

None of these announce themselves. Each is a silent return to chapter 1. The difference between a site that stays optimised and one that does not is nothing to do with skill — it is whether anything is watching.

Monitors

A monitor is a URL, an objective and an interval: hourly, 6-hourly, daily or weekly. Each run is a full analysis that feeds History and Trends and raises an alert when something regresses.

The Monitors view: a form for URL, keyword, objective and interval, a notice that monitors run only while Sjá is open unless background runs are enabled, and a run log.

What to monitor, and at what interval, follows from what each page costs you if it breaks:

  • Daily — the three or four pages that earn the money. Landing, pricing, the top-converting docs page.
  • Weekly — one page per template. If the docs template breaks, one docs page will tell you.
  • Hourly — almost never. The useful signal is the launch day of a big redesign, and then you should turn it back down.

Remember from chapter 3 that the Track changes objective creates the monitor as part of the first run. The best time to set up monitoring is while you are already looking at the page.

The sentence that makes it work

Monitors run only while Sjá is open. This is the thing most people miss, and the app says it in a banner rather than letting you find out: a daily monitor on a laptop you close every evening is not a daily monitor. It is a monitor that runs whenever you happen to have the app in front of you, which is precisely the pattern you were trying to escape.

Turn on background runs and Sjá installs a small scheduled job with launchd that performs the runs whether or not the app is open. Now a daily monitor is daily.

A run log that admits failure

Every attempted run is recorded — from the app and from the background agent — and a failed run says why. This matters more than it sounds. A monitoring system whose failures are silent is worse than no monitoring, because it produces confident quiet that you interpret as good news. A gap in your history means “nothing went wrong”; a failed run that says connection refused means your site was down.

Failures are retried at 15, 30 and 60 minutes after the first three failures, then the monitor returns to its normal interval. The backoff exists so a five-minute outage does not produce a gap in your trend line, and so a three-day outage does not produce a thousand futile requests. And a run whose process never finished is marked failed with that as the reason, rather than sitting as “running” forever.

Trends plots the score for a URL over time, overall and per category. The value is not the line going up. It is the step where it went down.

Freddy's Structure score sat at 92 for six weeks and dropped to 71 on a Tuesday in October. Compare that run against the one before it and the diff is exact: the new hero component renders the page title in a <div>, so the page now has no <h1> at all.

Nobody would have noticed. The page looks identical; the title is the same size and the same colour. Without the monitor, this is found in six months by somebody investigating a traffic decline, and by then it has been copied into four more templates.

Alerts are the point of all of it. A regression that raises an alert is a ten-minute fix. The same regression found by a quarterly audit is an archaeology project across a season of commits — same bug, twenty times the cost, plus a season of lost traffic nobody gets back.

What you learned

  • Optimisation decays suddenly, on the day somebody ships something.
  • Monitor by consequence: daily for the pages that earn, weekly for one page per template.
  • Monitors run only while the app is open unless you turn on background runs. Otherwise a daily monitor is not daily.
  • A failed run says why, because silent failure is worse than no monitoring.
  • Retries at 15, 30 and 60 minutes so a short outage does not become a hole in the trend.
  • The value of a trend is the step down, and comparison tells you exactly what changed that day.
Next: in Chapter 13 you stop the regression from ever reaching production: Sjá in your build pipeline, with per-category budgets and an exit code that means something.