Site Colour Palette — What Your Page Actually Renders
This extracts the colours actually present on a rendered page — not the ones in your design tokens or your stylesheet, but the ones a browser ended up painting. The two diverge more than anyone expects, and the divergence accumulates quietly.
When it helps
Because design systems leak. A component library ships its own defaults for a state nobody styled. A third-party widget brings its own palette. A one-off colour is added under deadline pressure because the token set does not quite cover a case, and it is never reconciled. Extracting the real palette turns "the site looks slightly inconsistent" into a specific list of colours that are not in the system, which is something you can act on.
Worth running automatically
The failure worth catching automatically is more severe than drift: a stylesheet that failed to load renders the page in browser defaults, and a page can be entirely functional while looking completely wrong. Comparing the extracted palette against an expected set on a schedule detects that in a way no status-code check ever will — the CSS request returning 404 does not make the page request fail. It also catches a third-party widget updating and bringing new colours with it.
What you get out of it
Measures what the page actually renders rather than what the source specifies. Its best trick is detecting a stylesheet that silently failed to load, which otherwise reaches production looking fine to every automated check.