This is the point of Betterloop. Everything below was written by the real engine and ranked so the most costly problem sits at the top. No one hand-wrote these.
Two kinds of input feed it, and both are generated for this demo: 7 days of browser traffic, which you can see in the other tabs, and observations from 5 connected sources (GitHub, PageSpeed Insights, Plausible Analytics, Site audit, Stripe). What is real is everything after that: the detectors, the thresholds, the ranking, and the findings that only exist because two sources were read together. The AI layers ran on top of the deterministic ones.
In a real project each card carries Acknowledge / Mark done / Dismiss buttons, and the same feed is pushed to Slack or pulled into Claude Code over MCP. The demo is read-only, so the controls are hidden here.
bugseverity: high/checkoutrules
JS error hitting 28 sessions: Cannot read properties of undefined (reading 'zip')
"Cannot read properties of undefined (reading 'zip')" fired 40 times across 28 sessions in the last 7 days (sample page: /checkout).
Top of stack:
TypeError: Cannot read properties of undefined (reading 'zip')
at validateAddress (checkout.4f2a1c9.js:118:22)
at handleSubmit (checkout.4f2a1c9.js:204:9)
evidence: message=Cannot read properties of undefined (reading 'zip') sessions=28 occurrences=40
reliabilityseverity: highfrom GitHubrules
CI fails 34% of the time
34 of the last 100 workflow runs failed, most of them in the checkout integration suite. It went from 12 to 34 % between 2026-10-25 and 2026-10-28, measured by GitHub. A step change like this usually has one cause you can find in what shipped during that window, which makes it far cheaper to chase now than after it becomes the baseline everyone forgets was ever different.
evidence: unit=% since=2026-10-25T19:16:43.750Z value=34 target=acme/storefront movedTo=34 sources=["github"] changePct=183 movedFrom=12 worstWorkflow=checkout-e2e
uxseverity: high/cartrules
Users rage-click "Apply promo code" on /cart
26 different sessions rapidly clicked the same element (form.promo-form>button#apply-promo) 51 times total in the last 7 days. That usually means it looks broken, is too slow to respond, or does not give feedback. Check its loading/disabled states and make the response instant or visibly in progress.
evidence: clicks=51 selector=form.promo-form>button#apply-promo sessions=26 windowDays=7
functionalseverity: high/checkoutfrom Plausible Analytics + GitHub + Site audit + PageSpeed InsightsAI
The checkout zip crash, the rage-clicks and the failing checkout tests are likely one problem
25 sessions hit "Cannot read properties of undefined (reading 'zip')" on /checkout, a page that only had 39 sessions in the same week. Own telemetry also shows 72 rage clicks in 7 days, and CI fails 34% of runs, mostly in the checkout integration suite. So the failing suite should have caught this and is being ignored or re-run. The 4 unlabelled checkout fields may be part of the cause, since autofill and labels affect how address data is populated. Reproduce the crash with an autofilled and a screen-reader-filled address, add that as a test, and make the checkout suite a blocking gate once it is stable.
evidence: target=/checkout sources=["plausible","github","site_audit","pagespeed"] cart_sessions=70 rage_clicks_7d=72 checkout_sessions=39 zip_error_sessions=25 ci_failure_rate_pct=34 unlabelled_checkout_fields=4
reliabilityseverity: highfrom Plausible Analytics + GitHub + Site audit + own_telemetryAI
Checkout throws for 26 of 40 sessions while CI's failing suite is checkout itself
The 'zip' error hit 26 sessions on /checkout, and /checkout had 40 sessions in the same week, so most people who reached payment hit a script error. GitHub shows 34 of the last 100 workflow runs failing, mostly in the checkout integration suite, alongside 31 commits in 7 days and a release 3 days ago. A red checkout suite that people merge past is the likeliest way this bug reached production. Make the checkout suite a required check on main, fix the zip-handling regression, and check whether the zip field is one of the 4 unlabelled inputs, since a missing label would also break autofill.
evidence: target=acme/storefront sources=["plausible","github","site_audit","own_telemetry"] commits_7d=31 checkout_sessions=40 days_since_release=3 zip_error_sessions=26 ci_failure_rate_pct=34 unlabelled_checkout_inputs=4
securityseverity: high/checkoutfrom GitHub + Site audit + Plausible Analytics + own_telemetryAI
Checkout is simultaneously the least secure, least accessible and least reliable page
The checkout flow concentrates failures across every connected source: CI fails on 34% of runs with most failures in the checkout integration suite, the session cookie that protects it has no SameSite attribute, 4 form fields have no label, and a published prototype-pollution vulnerability sits in the payment form's own validation library with no Content-Security-Policy to contain it if it's exploited. Users are already hitting this - 21 sessions threw an undefined-zip error on checkout. This is the one page where a security or reliability failure costs revenue directly, not just traffic. Prioritize a checkout-specific hardening pass: fix the CI suite first so regressions stop shipping, then add SameSite and a CSP before the dependency patch lands.
evidence: target=/checkout sources=["github","site_audit","plausible","own_telemetry"] zip_error_sessions=21 ci_failure_rate_pct=34 unlabeled_fields_checkout=4 high_sev_dependabot_alerts=3
performanceseverity: highrules
Real users see a much slower page than the lab test does
Chrome's field data puts LCP at 5400ms while the synthetic Lighthouse run measured 3100ms on the same page. Your actual audience is on slower devices, worse networks, or hitting a cold cache far more often than the test does. Optimise against the field number - the lab one is already telling you a story that is true for nobody.
evidence: url=https://shop.acme-demo.example labLcpMs=3100 fieldLcpMs=5400
productseverity: high/blog/how-we-sourcerules
96% of visitors leave /blog/how-we-source without going anywhere
88 of 92 sessions that started on /blog/how-we-source viewed nothing else in the last 7 days. Either the page does not deliver what visitors expected, or the next step is not obvious. Check the primary call to action above the fold and whether the page matches its traffic sources.
evidence: bounced=88 sessions=92 bounceRate=0.96
reliabilityseverity: highfrom GitHub + own_telemetry + Site auditAI
Checkout is failing for real users while CI's checkout suite is also red
The 'zip' error hit 28 of the 41 sessions that reached /checkout this week, and the GitHub failures are mostly in the checkout integration suite (34 of the last 100 runs failed). The repo had 31 commits in 7 days and a release 3 days ago, so changes are reaching production while the gate that covers this exact flow is red. Bisect the 3-day-old release against the first appearance of the zip error and fix that regression. Then make the checkout integration suite a required check so a red run blocks merge. Also test whether the 4 unlabelled checkout fields break autofill and leave the address object undefined, since that is a plausible cause of the zip error.
evidence: target=acme/storefront /checkout sources=["github","own_telemetry","site_audit"] commits_7d=31 checkout_sessions=41 days_since_release=3 zip_error_sessions=28 ci_failure_rate_pct=34 unlabelled_checkout_fields=4
reliabilityseverity: highfrom GitHub + own_telemetry + StripeAI
Checkout is failing in CI, in production, and at the bank all at once
The checkout integration suite is the main source of the 34% CI failure rate, the live site is throwing a zip-read error to 27 sessions on /checkout, and Stripe logged 27 failed payments in the last 30 days. None of these numbers prove one root cause, but together they describe a checkout path that is unstable at every layer: code, browser, and payment processor. This is the page that converts revenue, so instability here has a direct commercial cost beyond any single bug ticket. Prioritize stabilizing and re-testing the checkout integration suite before merging further changes to that path, and add monitoring that ties JS errors on /checkout to payment outcomes.
evidence: target=acme/storefront:/checkout sources=["github","own_telemetry","stripe"] ci_fail_rate_pct=34 failed_payments_30d=27 active_subscriptions=412 checkout_zip_error_sessions=27
pricingseverity: highfrom GitHub + own_telemetry + StripeAI
A broken, unstable checkout is a plausible driver of the 8.7% subscription churn
CI fails 34% of the time and most failures are in the checkout integration suite, own telemetry shows a checkout-specific crash hitting 30 sessions plus 27 failed payments in 30 days, and Stripe shows 36 of 412 subscriptions (8.7%) cancelling in the same window. These are not independent facts: a checkout that a test suite cannot reliably pass, and that visibly errors for real users, is exactly the kind of friction that turns a failed renewal or a frustrating experience into a cancellation instead of a retry. At $44.70 ARPU, even a modest share of that churn tied to checkout failures is recoverable revenue. Prioritize stabilizing the checkout CI suite and shipping a fix for the zip-read crash before running any retention or win-back campaign, since the leak may be upstream of pricing.
evidence: target=acme/storefront sources=["github","own_telemetry","stripe"] cancelled=36 ci_fail_rate=34 churn_30d_pct=8.7 zip_error_sessions=30 failed_payments_30d=27 active_subscriptions=412
securityseverity: highfrom GitHub + Site audit + own_telemetryAI
The exact checkout code path that crashes for users also ships a public prototype-pollution flaw
Github's dependabot alert names a prototype-pollution vulnerability in the payment form's validation library, and telemetry shows that same checkout page throwing 'Cannot read properties of undefined (reading zip)' in 23 sessions this week, a shape-of-object failure consistent with the same validation code. CI failures are concentrated in the checkout integration suite at a 34% fail rate, meaning the tests that would catch a payment-form regression are themselves unreliable right now. This is not three separate problems, it is one fragile, exploitable, poorly-tested surface sitting directly in front of revenue. Patch the validation library dependency first, then use the fix to also stabilize the zip-field crash before touching anything else in checkout.
evidence: target=acme/storefront:/checkout sources=["github","site_audit","own_telemetry"] dependabot_high=3 ci_fail_rate_pct=34 checkout_error_sessions=23
functionalseverity: highfrom GitHub + own_telemetry + StripeAI
The checkout suite that CI keeps failing is the same one throwing the zip-code crash and failing payments
GitHub shows checkout integration tests failing in 34 of the last 100 CI runs, and in production the exact same page throws "Cannot read properties of undefined (reading 'zip')" in 19 sessions this week. Stripe shows 27 failed payments in the last 30 days, and checkout only gets 36 sessions this week against 70 on /cart, so a meaningful share of the funn that reaches checkout is hitting a code path nobody's tests are passing. Fix the address/zip handling that the integration suite is failing on before merging anything else into that file, then confirm failed-payment count drops on the next Stripe pull. This is the one place all three systems agree something is broken.
evidence: target=acme/storefront:checkout sources=["github","own_telemetry","stripe"] ci_failure_rate_pct=34 failed_payments_30d=27 checkout_weekly_sessions=36 checkout_zip_error_sessions=19
productseverity: high/checkoutfrom GitHub + StripeAI
Checkout crashes for most sessions that make it past cart, and CI can't catch it
Cart draws 70 sessions but checkout only sees 40, and of those 40 sessions 25 hit the 'reading zip' crash - meaning the majority of people who reach checkout run into a page that throws before they can pay. GitHub's CI is failing 34% of the time with most failures in the checkout integration suite, which is exactly the code path where this crash lives, so the tests that should have caught it are themselves unreliable. Stripe shows 27 failed payments in the last 30 days on top of this, compounding revenue loss from a page that is both crashing and mis-billing. Fix the checkout suite's flakiness first so a real regression test for the zip-read crash can actually gate merges, then ship the fix. This is the highest-traffic revenue page in the funnel and it is currently the least trustworthy one.
evidence: target=/checkout sources=["github","stripe"] cart_sessions=70 ci_fail_rate_pct=34 checkout_sessions=40 zip_error_sessions=25 failed_payments_30d=27
a11yseverity: highfrom Site auditrules
4 form fields have no label
Four inputs on the checkout have no <label for>, no aria-label and no aria-labelledby. Unlabelled fields are unusable with a screen reader and unhelpful with autofill, which costs completions from everyone rather than only assistive-tech users.
evidence: unit=count value=4 target=https://shop.acme-demo.example/checkout sources=["site_audit"]
securityseverity: highfrom GitHubrules
3 open high-severity dependency alerts
Three published vulnerabilities in packages this repo ships, including a prototype-pollution issue in the payment form's validation library. The exploits are public by definition - that is what publication means.
evidence: unit=count value=3 target=acme/storefront sources=["github"]
reliabilityseverity: highfrom GitHub + own_telemetryAI
Checkout is failing in CI and in production, and the errors hit 23 of 40 checkout sessions
GitHub shows 34 of the last 100 workflow runs failing, mostly in the checkout integration suite. Own telemetry shows the 'zip' TypeError in 23 sessions on /checkout, which received 40 sessions in total. The team shipped 31 commits in 7 days and released 3 days ago, so changes are reaching production while the suite covering this exact flow is red. Treat the failing checkout tests as the detector for the zip bug. Reproduce the failure from the CI logs, fix it, and make that suite a required check before merge.
evidence: target=acme/storefront and /checkout sources=["github","own_telemetry"] commits_7d=31 checkout_sessions=40 days_since_release=3 zip_error_sessions=23 ci_failed_runs_of_100=34
pricingseverity: highfrom Plausible Analytics + StripeAI
A checkout error hitting most checkout sessions lines up with 27 failed payments a month
25 of the 37 sessions that reached /checkout this week hit the 'reading zip' error, meaning roughly two in three checkout attempts encountered a JS crash before or during payment entry. Stripe separately logs 27 failed payments in the last 30 days against 412 active subscriptions, a volume consistent with customers who could not complete the zip-code step and either abandoned or retried with errors. There is no way to split these from pure card declines in the current data, but the overlap in both timing and page is too large to ignore. Fix the null-reference bug on the zip field first, then check whether failed-payment volume drops in the following billing cycle.
evidence: target=https://shop.acme-demo.example/checkout sources=["plausible","stripe"] checkout_views=37 zip_error_sessions=25 failed_payments_30d=27 active_subscriptions=412
pricingseverity: mediumfrom Striperules
30 day subscription churn: 8.7%
36 of 412 subscriptions cancelled in the last 30 days. At that rate the customer base turns over roughly every 11 months, so growth has to outrun the leak before it can compound. It went from 5.1 to 8.7 % between 2026-10-25 and 2026-10-28, measured by Stripe. A step change like this usually has one cause you can find in what shipped during that window, which makes it far cheaper to chase now than after it becomes the baseline everyone forgets was ever different.
evidence: unit=% since=2026-10-25T19:16:43.750Z value=8.7 movedTo=8.7 sources=["stripe"] changePct=71 movedFrom=5.1
performanceseverity: mediumfrom PageSpeed Insightsrules
LCP from real Chrome users (CrUX) moved 69% in the wrong direction
It went from 3,200 to 5,400 ms between 2026-10-25 and 2026-10-28, measured by PageSpeed Insights. A step change like this usually has one cause you can find in what shipped during that window, which makes it far cheaper to chase now than after it becomes the baseline everyone forgets was ever different.
evidence: to=5400 from=3200 unit=ms since=2026-10-25T19:16:43.750Z sources=["pagespeed"] changePct=69
performanceseverity: highrules
Lighthouse performance score is 41/100 on mobile
Google's own audit of https://shop.acme-demo.example/product/aurora-lamp scores 41 for performance on mobile. Mobile is the profile Google ranks on, so this number affects acquisition and not only experience. The individual failing audits appear as their own insights where they carry a measurable saving. It went from 68 to 41 score between 2026-10-25 and 2026-10-28, measured by PageSpeed Insights. A step change like this usually has one cause you can find in what shipped during that window, which makes it far cheaper to chase now than after it becomes the baseline everyone forgets was ever different.
evidence: url=https://shop.acme-demo.example/product/aurora-lamp score=41 since=2026-10-25T19:16:43.750Z movedTo=41 category=performance strategy=mobile changePct=40 movedFrom=68
seoseverity: medium/productsfrom Plausible Analytics + Site audit + PageSpeed Insights + own_telemetryAI
Google brings in the traffic and /products is its landing page, so fix that route first
Google is the top referrer with 780 visits and /products is the top entry page with 610 entries. That page has no meta description, a JS error on 5 sessions, and sits on an origin whose real-user LCP is 5400ms. The site-wide bounce rate is 61% with 2.4 pages per visit, so visitors who arrive from search are not going deeper. Do the /products meta description and the variants.length fix before structured data on individual product pages. Then re-check bounce rate on that entry page to see whether the snippet and load time were the problem.
evidence: target=/products sources=["plausible","site_audit","pagespeed","own_telemetry"] crux_lcp_ms=5400 google_visits=780 bounce_rate_pct=61 pages_per_visit=2.4 products_entries=610 products_error_sessions=5
pricingseverity: mediumrules
27 failed payments against 412 active subscriptions
Involuntary churn - expired cards, insufficient funds, issuer declines - is revenue you already earned and then lost to plumbing, from customers who never decided to leave. It is the cheapest retention work available: card-expiry reminders before the charge, a dunning sequence with real retries, and Stripe's automatic card updater. Expired cards, insufficient funds and issuer declines - revenue already earned and then lost to plumbing, from customers who never decided to leave.
evidence: failedPayments30d=27 activeSubscriptions=412
growthseverity: mediumrules
Roughly 84% of your visitors never reach client-side analytics
Plausible counted 2,140 visitors over the last 7 days; our in-browser SDK saw 338 sessions. One measures at the edge and the other inside the page, so a gap this size usually means ad blockers, Do Not Track and privacy browsers - though it can also mean the snippet is missing from some pages, which is worth ruling out first. Note: this is measured against unique visitors rather than visits, because your Plausible connection has not reported a visit count - so if people return during the week, the real gap is larger than this. Two consequences: every client-side number you look at - conversion, funnels, session counts - is an undercount by about this much, and the missing group skews technical, which is exactly who you least want to be blind to.
evidence: comparedTo=visitors coveragePct=16 sdkSessions7d=338 plausibleVisitors7d=2140
seoseverity: mediumfrom Site auditrules
No structured data on product pages
No application/ld+json was found. Product schema is what produces the price, availability and rating shown under a search result, and it is the difference between a plain link and a rich one on a page whose whole job is selling.
evidence: unit=count value=0 target=https://shop.acme-demo.example/product/aurora-lamp sources=["site_audit"]
seoseverity: mediumfrom Site auditrules
No meta description
The product listing has no meta description, so Google writes the snippet from whatever text it finds. That snippet is the ad copy for every search result the page appears in.
evidence: unit=count value=0 target=https://shop.acme-demo.example/products sources=["site_audit"]
performanceseverity: mediumfrom Site auditrules
5 render-blocking tags in <head>
Three synchronous scripts and two stylesheets block the first paint. Nothing renders until all five have downloaded and executed.
evidence: unit=count value=5 target=https://shop.acme-demo.example sources=["site_audit"]
securityseverity: mediumfrom Site auditrules
No Content-Security-Policy
No Content-Security-Policy header or meta tag was returned, so any injected script - from a compromised dependency, an ad tag or a stored-XSS payload - runs with full access to the page and to logged-in sessions.
evidence: unit=bool value=0 target=https://shop.acme-demo.example sources=["site_audit"]
securityseverity: mediumfrom Site auditrules
Session cookie is missing SameSite
acme_session is set with Secure and HttpOnly but no SameSite attribute, so it is attached to cross-site requests and the checkout is reachable by CSRF.
evidence: unit=count value=1 target=acme_session sources=["site_audit"]
a11yseverity: mediumfrom Site auditrules
23 images have no alt text
Counted in the server-rendered HTML, so this is a lower bound. Product imagery announced as "image" gives a screen reader nothing, and gives search engines nothing either.
evidence: unit=count value=23 target=https://shop.acme-demo.example sources=["site_audit"]
performanceseverity: mediumfrom PageSpeed Insightsrules
Reduce unused JavaScript: 2,400ms
402KB of JavaScript is parsed before anything is interactive and never used on this page.
evidence: unit=ms value=2400 target=https://shop.acme-demo.example/product/aurora-lamp sources=["pagespeed"] savingsMs=2400 savingsBytes=412000
performanceseverity: mediumfrom PageSpeed Insightsrules
Serve images in a modern format at the right size: 1,800ms
The hero image is a 1.9MB PNG served at 3x the size it renders at.
evidence: unit=ms value=1800 target=https://shop.acme-demo.example/product/aurora-lamp sources=["pagespeed"] savingsMs=1800 savingsBytes=1940000
securityseverity: mediumfrom GitHubrules
11 open medium-severity dependency alerts
GitHub flagged this on acme/storefront (11).
evidence: unit=count value=11 target=acme/storefront sources=["github"]
functionalseverity: medium/product/aurora-lamprules
Clicking "Size chart" on /product/aurora-lamp does nothing
9 sessions clicked this interactive-looking element (div.pdp-specs>span.size-chart) with no visible reaction - no navigation, no DOM change. Either the handler is broken, or the element should not look clickable. 17 dead clicks in 7 days.
evidence: clicks=17 selector=div.pdp-specs>span.size-chart sessions=9 windowDays=7
functionalseverity: medium/product/nomad-backpackrules
Clicking "Only 3 left" on /product/nomad-backpack does nothing
9 sessions clicked this interactive-looking element (div.pdp-buy>span.stock-badge) with no visible reaction - no navigation, no DOM change. Either the handler is broken, or the element should not look clickable. 16 dead clicks in 7 days.
evidence: clicks=16 selector=div.pdp-buy>span.stock-badge sessions=9 windowDays=7
a11yseverity: mediumrules
Lighthouse fails 3 accessibility checks
Text has insufficient colour contrast; Form elements have no associated labels; Links have no discernible name. These are automated checks, so they are the floor rather than the ceiling of what is wrong - but every one is a concrete, reproducible defect with a known fix, which makes them the cheapest accessibility work you will ever do.
evidence: url=https://shop.acme-demo.example/product/aurora-lamp failed=["Text has insufficient colour contrast","Form elements have no associated labels","Links have no discernible name"]
uxseverity: medium/checkoutrules
Users rage-click "Place order" on /checkout
8 different sessions rapidly clicked the same element (button#place-order) 15 times total in the last 7 days. That usually means it looks broken, is too slow to respond, or does not give feedback. Check its loading/disabled states and make the response instant or visibly in progress.
evidence: clicks=15 selector=button#place-order sessions=8 windowDays=7
performanceseverity: high/product/aurora-lamprules
/product/aurora-lamp is slow: LCP p75 is 6129ms
The 75th percentile LCP on /product/aurora-lamp is 6129ms over 76 samples (7 days). Google rates LCP above 4000ms as "poor". Check hero image size, render-blocking scripts, and server response time.
evidence: p75=6129 metric=LCP samples=76
performanceseverity: high/product/nomad-backpackrules
/product/nomad-backpack is slow: LCP p75 is 5516ms
The 75th percentile LCP on /product/nomad-backpack is 5516ms over 48 samples (7 days). Google rates LCP above 4000ms as "poor". Check hero image size, render-blocking scripts, and server response time.
evidence: p75=5516 metric=LCP samples=48
a11yseverity: mediumrules
Lighthouse accessibility score is 72/100 on mobile
Google's own audit of https://shop.acme-demo.example/product/aurora-lamp scores 72 for accessibility on mobile. Mobile is the profile Google ranks on, so this number affects acquisition and not only experience. The individual failing audits appear as their own insights where they carry a measurable saving.
evidence: url=https://shop.acme-demo.example/product/aurora-lamp score=72 category=accessibility strategy=mobile
bugseverity: high/productsrules
JS error hitting 5 sessions: undefined is not an object (evaluating 'p.variants.length')
"undefined is not an object (evaluating 'p.variants.length')" fired 8 times across 5 sessions in the last 7 days (sample page: /products).
Top of stack:
TypeError: undefined is not an object (evaluating 'p.variants.length')
at renderCard (catalog.71c0d2.js:88:15)
at ProductGrid (catalog.71c0d2.js:141:7)
evidence: message=undefined is not an object (evaluating 'p.variants.length') sessions=5 occurrences=8
performanceseverity: high/cartrules
/cart is slow: INP p75 is 547ms
The 75th percentile INP on /cart is 547ms over 21 samples (7 days). Google rates INP above 500ms as "poor". Look for long tasks blocking the main thread on interaction - heavy handlers, large re-renders.
evidence: p75=547 metric=INP samples=21
pricingseverity: lowrules
1 of your 3 plans have no subscribers
Everyone is clustered on Starter - $19/mo, while Scale - $149/mo has no takers at all. Unused tiers are not free: every extra column on the pricing page costs comprehension before it costs anything else, and a tier nobody picks is either priced wrong or describes a customer you do not have.
evidence: plans=[{"plan":"Growth - $49/mo","subscribers":168},{"plan":"Scale - $149/mo","subscribers":0},{"plan":"Starter - $19/mo","subscribers":244}]
bugseverity: medium/accountrules
JS error hitting 4 sessions: Failed to fetch orders: 503 Service Unavailable
"Failed to fetch orders: 503 Service Unavailable" fired 7 times across 4 sessions in the last 7 days (sample page: /account).
Top of stack:
TypeError: Failed to fetch
at loadOrders (account.9b1ef04.js:64:11)
at async OrdersPanel (account.9b1ef04.js:96:3)
evidence: message=Failed to fetch orders: 503 Service Unavailable sessions=4 occurrences=7
seoseverity: lowrules
Lighthouse seo score is 78/100 on mobile
Google's own audit of https://shop.acme-demo.example/product/aurora-lamp scores 78 for seo on mobile. Mobile is the profile Google ranks on, so this number affects acquisition and not only experience. The individual failing audits appear as their own insights where they carry a measurable saving.
evidence: url=https://shop.acme-demo.example/product/aurora-lamp score=78 category=seo strategy=mobile
codeseverity: lowfrom GitHubrules
Oldest open pull request is 47 days old
A branch open for 47 days has drifted far enough from main that merging it is its own project, and the review it finally gets will be too large to be a real review.
evidence: unit=count value=47 target=acme/storefront sources=["github"]
codeseverity: lowrules
60% of open issues are over 90 days old
41 of 68 open issues on acme/storefront have sat untouched for more than three months. A backlog that old stops being a plan and becomes a place things go to be forgotten - which means real reports get buried alongside the stale ones. Closing what you will not do is what makes the rest trustworthy.
evidence: open=68 repo=acme/storefront stale=41
performanceseverity: medium/checkoutrules
/checkout is slow: LCP p75 is 3164ms
The 75th percentile LCP on /checkout is 3164ms over 26 samples (7 days). Google rates LCP above 2500ms as "needs improvement". Check hero image size, render-blocking scripts, and server response time.
evidence: p75=3164 metric=LCP samples=26
performanceseverity: medium/checkoutrules
/checkout is slow: INP p75 is 201ms
The 75th percentile INP on /checkout is 201ms over 15 samples (7 days). Google rates INP above 200ms as "needs improvement". Look for long tasks blocking the main thread on interaction - heavy handlers, large re-renders.
evidence: p75=201 metric=INP samples=15
productseverity: medium/accountrules
75% of visitors leave /account without going anywhere
9 of 12 sessions that started on /account viewed nothing else in the last 7 days. Either the page does not deliver what visitors expected, or the next step is not obvious. Check the primary call to action above the fold and whether the page matches its traffic sources.
evidence: bounced=9 sessions=12 bounceRate=0.75