Stacks rot silently.
A version ships, a vulnerability lands, nobody notices until it costs. Why stacks decay, how to check yours - and what an audit automates.
Three ways a stack decays
None of them announce themselves. Each one has a public data source you can check by hand today - and each check is exactly what an audit runs for you, on every technology it detects.
The runtime stops getting patches
Every release line has an end-of-life date. After it, security fixes stop - the code keeps working, and that is the problem: nothing breaks, so nobody looks, while every new vulnerability stays unpatched forever.
Check it yourself: endoflife.date lists the support windows for hundreds of technologies.
An audit reads the versions your site actually runs and flags the lines that are past - or approaching - their end of life.
Old versions carry published CVEs
Most compromised dependencies are not zero-days - they are known, published vulnerabilities in versions that were simply never updated. The fix usually exists; it just was not installed.
Check it yourself: osv.dev is the open database of known vulnerabilities, searchable by package and version.
An audit matches every detected version against that database and lists what applies to your stack - without needing access to your code.
Performance and accessibility erode
Every added script, image and integration moves the needle a little. Without a baseline nobody notices the drift - until the page is slow and the audit that finally runs explains why.
Check it yourself: PageSpeed Insights runs a free Lighthouse audit on any URL.
An audit runs Lighthouse for you - performance, accessibility, best practices, SEO - and keeps the history, so drift becomes a visible line, not a feeling.
One weak link sets the score
The Awesomeness Score weights weak results far more heavily than strong ones - a dimension in the low band carries nine times the weight of one in the high band, a middling one three times. That is how real risk behaves: ten great choices do not cancel one vulnerable dependency.
The 41 carries nine times the weight of the two high scores - so the score says what needs fixing first, not how good the average looks.
A dimension without a measurable basis drops out and its weight renormalizes over the rest - the report marks such audits as incomplete. The full recipe is published in the methodology, so you can check our work.
A health check, not a sales tool
Most technology-detection products exist to turn other people's stacks into lead lists. AwesomeTechStack points the same detection at your own site - the question is not "what do they run", it is "how healthy is what we run". We do not sell lead lists, and audits exist for the site owner, not for whoever wants to sell to them.
Alerts beat snapshots
An audit is a snapshot, and snapshots go stale - the ecosystem moves whether you re-audit or not. Stack Watch watches the live stack and logs every change the moment a threshold tips, so you catch an end-of-life runtime, an expiring certificate or a fresh vulnerability before your users do.
- Known vulnerabilities, via osv.dev
- End-of-life dates for detected release lines
- Version drift against the latest releases
- Certificate expiry
- Score changes between audits
Webhook delivery is live; email delivery is coming. The audit is the entry point - the watch is the value.
Run your first audit.
Free account, 5 audits a month, no credit card.