The Gate
A monitor tells you the site broke. A gate stops it breaking. This chapter puts Sjá in the pipeline, where the cost of a mistake is a failed build rather than a quarter of lost traffic.
The problem
Chapter 12 is detection, and detection is always after the fact. The regression shipped. It was live for some number of hours before the monitor ran, and somebody now has to interrupt their week to revert it.
Everything else your team cares about is already defended at the pull request: tests, types, lint, formatting. SEO and GEO are the only qualities with real business consequences that are conventionally checked after deploy, by a human, occasionally. There is no reason for that other than habit and tooling.
Headless
Sjá runs from the command line with no interface, prints its result, and exits with a meaningful code.
elyra-sja analyze https://staging.freddy.app --objective audit --min-score 80 --min-category meta=90 --min-category indexing=100 --json report.jsonPass the licence through an environment variable so no key is committed, and wire it into whatever runs your tests.
Two failures that must stay separate
The exit codes are the most carefully designed thing in this chapter, and the reason is worth a paragraph.
| Code | Meaning | What your pipeline should do |
|---|---|---|
0 |
Analysis ran; every budget met | Continue |
1 |
Analysis ran; a budget was not met | Fail the build — this is a real regression |
2 |
The analysis could not run at all | Fail loudly, but do not blame the commit |
Collapsing 1 and 2 into “non-zero” is the mistake that kills these gates. If a network blip, an expired licence or an unreachable staging host produces the same red X as a genuine drop in score, the team learns within two weeks that the check is flaky — and a flaky check is ignored, then disabled. Keeping the two apart is what makes the gate survive contact with a real team.
Budgets, per category
An overall minimum is a blunt instrument: it lets a catastrophic Indexing failure hide behind excellent Meta and Structure scores. Per-category budgets let you say what you actually mean.
-
indexing=100— nothing less is acceptable. Anoindexreaching production is the single most expensive mistake in this discipline, and it is a one-character mistake. -
meta=90— titles and descriptions are template-driven; a drop means somebody changed a template. -
Overall
80— room to work without room to rot.
Set them at today's numbers minus a point or two, not at your ambition. A budget is a ratchet against regression, not a target. Budgets set above the current score fail on day one and get deleted on day two.
Where to run it
Against staging, on every pull request. This is the version that prevents rather than reports. The failure lands on the person who caused it, while the change is still in their head, which is where a fix costs ten minutes.
Against production, after deploy. A second gate that catches what only differs in production — a CDN rule, an environment variable, a cache. Chapter 6 was full of those.
Not on a nightly cron. That is chapter 12's job, and it is already doing it better.
What you learned
- A gate prevents; a monitor reports. You want both, doing different jobs.
- Exit 1 and exit 2 must stay separate. A gate that cannot tell a regression from an outage becomes a gate nobody trusts.
- Per-category budgets stop a catastrophe hiding behind an average.
- indexing=100 is the one budget everyone should set. A one-character mistake, the most expensive outcome.
- Set budgets at today minus a point, because a budget is a ratchet and not an ambition.
- A budget on an unmeasured category fails, correctly. There is no guarantee to give.