Tools we recommend
The tools we point people at, grouped by the problem they solve, each with what it does not do and where the recommendation came from.
Fixes something a scan found
Our report names these when it finds the problem they answer. Each entry says which finding sends you here and links the article about it.
Knowing the site is down
A scan tells you about one moment. Something has to watch the other moments.
- Go to UptimeRobot
UptimeRobot
UptimeRobot checks a URL from outside your network on a schedule and tells you when it stops answering, which one scan of one page cannot.
Doesn't do Every monitor UptimeRobot offers runs from outside, against an address. An alert tells you the endpoint stopped answering and cannot tell you which code path broke, so it belongs alongside something that reads your application's own errors rather than instead of it.
Seeing what broke for a real visitor
We read one load of one page. Whatever throws on the third step of a checkout throws somewhere we were never looking.
- Go to Sentry
Sentry
Sentry catches the exceptions real visitors hit, folds them into one issue with a stack trace, and names the commit most likely behind it.
Doesn't do It reports what your code threw. A page that renders the wrong total, or serves a stale cache, or silently drops a form submission, throws nothing at all, and no amount of error monitoring will raise its hand.
Keeping dependencies patched
The libraries behind a page are invisible from outside it, so this one has to be answered from inside the repository.
- Go to Dependabot
Dependabot
Dependabot watches what a GitHub repository declares it depends on, and opens a pull request when one of those packages has a published fix.
Doesn't do GitHub's own limitations list is blunt about it: Dependabot alerts cannot catch every security issue, only advisories GitHub has reviewed will trigger one, and a new vulnerability can sit for a while before it reaches the Advisory Database at all.
- Go to Snyk
Snyk
Snyk reads a dependency tree as software composition analysis, follows a flaw into indirect packages, and is not tied to one code host.
Doesn't do Releases are what it follows, not commits. Snyk's Open Source documentation states that only official releases are identified and that a commit merged to a default branch does not register unless it lands in a release or a tag, so a fix already sitting in main is invisible until somebody publishes it.
Finding out what a search engine did with the page
We can read the directives a page publishes about itself. Only the search engine can say which of them it acted on.
- Go to Google Search Console
Google Search Console
Our scan reads the indexing directives your page publishes. Search Console is where Google says what it actually did with them.
Doesn't do It answers for Google and nothing else. Bing, DuckDuckGo and every answer engine now quoting your content hold their own view of your site and their own reasons for dropping a page, and none of that surfaces here.
The timings we do not measure
One cold, unthrottled load gives bytes and a load milestone. It does not give Core Web Vitals, and our speed test page says so.
- Go to Lighthouse
Lighthouse
Core Web Vitals are the measurement our scan does not make. Lighthouse makes it, and PageSpeed Insights is the hosted way to run Lighthouse.
Doesn't do A score moves while your site stands still. Chrome's own scoring page lists the reasons: adverts or experiments serving differently between runs, traffic routing, the machine you happened to use, extensions injecting scripts, antivirus software. One Lighthouse run is a sample, not a measurement.
- Go to WebPageTest
WebPageTest
WebPageTest loads a page from a chosen region, device and connection, then puts every request on a waterfall beside a filmstrip of the load.
Doesn't do Tests queue behind other people's tests. WebPageTest's own quick start guide tells you to allow roughly a minute for each test ahead of yours and warns it is often longer, so this is a tool you sit down with rather than one you wire into a pull-request check.
Reaching the element a rule fired on
We run axe-core and keep how many nodes failed, never which ones. Reaching the node means running the rules where the page is.
- Go to axe DevTools
axe DevTools
Our scan runs axe-core and keeps the count, never the elements. The axe DevTools extension runs those rules in your browser and points at them.
Doesn't do Automation settles the questions that can be settled by reading markup. Whether a keyboard user can get back out of your modal, and what a screen reader actually announces once it is in there, are not among them, and running the same rules interactively does not move that boundary.
The connection behind the padlock
Our check is that a page arrived over HTTPS. What certificate, protocol and cipher carried it is a separate question entirely.
- Go to SSL Labs
SSL Labs
Our check is whether a page arrived over HTTPS at all. SSL Labs opens the handshake and grades the certificate, protocols and ciphers behind it.
Doesn't do It stops at the transport and says so in writing. The rating guide carries a section on what it does not cover, which states that a cookie left without the Secure attribute can be lifted by a determined attacker, that detecting web-application problems automatically is hard, and that this version does not attempt it. Our scan does read cookie attributes, response headers, indexing tags and accessibility rules on that same page in that same run. Depth on one thing against breadth in one pass: neither of us replaces the other.
What we build with
These are in our own stack. The reason to trust the recommendation is that we run it, so each entry says what in our repositories would show you that.
Where the data lives
Scan runs, reports and the articles on this site all come out of the same database.
- Go to Supabase
Supabase
Supabase is the Postgres under EngineeringScore. Scan runs, reports and the articles this site serves all sit in one Supabase project.
Doesn't do Supabase's row-level security guide says RLS is on by default only for tables made in the dashboard's table editor, and that a table created in raw SQL has to have it switched on by hand. Every table behind this product came out of a migration, which is raw SQL, so that default is not what protects us.
Where the app runs
What we chose to deploy on, and the thing we tried first that did not work.
- Go to AWS container hosting
AWS container hosting
The part of AWS we recommend is the plain part: your own container in your own VPC, which is what this frontend was rebuilt to be.
Doesn't do AWS Amplify Hosting, where this app ran first, cannot reach a private VPC from its server-rendering compute. The request for it is open on the Amplify Hosting issue tracker as a feature request, so we moved the frontend into a container rather than design around it.
Ready to see where you stand?
Scan your site and get your Engineering Score with a prioritized roadmap in under a minute, no signup required.
EngineeringScore