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 23 sessions: Cannot read properties of undefined (reading 'zip')
"Cannot read properties of undefined (reading 'zip')" fired 35 times across 23 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=23 occurrences=35
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-07-27 and 2026-07-29, 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-07-27T04:24:01.063Z 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
21 different sessions rapidly clicked the same element (form.promo-form>button#apply-promo) 44 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=44 selector=form.promo-form>button#apply-promo sessions=21 windowDays=7
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
securityseverity: highfrom GitHub + Site audit + StripeAI
Prototype-pollution alert sits in the exact library validating checkout's zip field
Github flags a published prototype-pollution vulnerability in the payment form's validation library, and the top production error is a null-reference on 'zip' hit by 23 sessions on /checkout, the field that library almost certainly parses. The same page is missing a Content-Security-Policy and the session cookie has no SameSite attribute, so an injected payload has both a way in and a way to ride along on requests, right on the page that carries the $18,420 approximate MRR flowing through Stripe. Patch the validation library first since it is both a security hole and the likely source of the zip crash, then add the CSP header and SameSite flag to close the surrounding gaps.
evidence: target=https://shop.acme-demo.example/checkout mrr_usd=18420 sources=["github","site_audit","stripe"] csp_missing=0 dependabot_high=3 samesite_missing=1 zip_error_sessions=23
reliabilityseverity: highfrom GitHub + Site auditAI
Failing CI in the checkout suite is shipping bugs straight to the page with the most fragile UX
CI fails 34% of the time and most failures are in the checkout integration suite, yet 31 commits landed in the last 7 days and a release went out 3 days ago. In that same window /checkout produced a JS error hitting 23 sessions and has 4 form fields with no accessible label at all. The pattern is a quality gate that is failing on the exact surface where real users are then hitting broken code, which means the gate is being routed around rather than fixed. Next action: block merges to checkout-touching code until the integration suite is green, and triage the current failures before shipping anything else there.
evidence: target=acme/storefront sources=["github","site_audit"] commits_7d=31 ci_fail_rate_pct=34 days_since_release=3 checkout_unlabeled_inputs=4 checkout_js_error_sessions=23
pricingseverity: high/checkoutfrom Stripe + GitHubAI
A crash hitting most checkout sessions sits on the page that feeds all $18,420 of MRR
Checkout gets 38 sessions this week and 23 of them hit the 'reading zip' crash, which is the majority of everyone who reaches the page that converts into the 412 active subscriptions generating roughly $18,420 in MRR. That is a bigger near-term revenue risk than the 27 failed payments or 8.7% churn already tracked, because those are people who converted once, while this crash may be stopping conversion before it happens at all. Treat the zip crash as a revenue-blocking incident and check whether its 23 affected sessions cluster on the same checkout step the CI integration suite keeps failing on.
evidence: target=/checkout mrr_usd=18420 sources=["stripe","github"] checkout_sessions=38 active_subscriptions=412 checkout_crash_sessions=23
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"]
productseverity: high/blog/how-we-sourcerules
93% of visitors leave /blog/how-we-source without going anywhere
84 of 90 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=84 sessions=90 bounceRate=0.93
bugseverity: high/checkoutfrom own_telemetry + StripeAI
Checkout crash on billing zip field lines up with 27 failed Stripe payments
The JS error 'Cannot read properties of undefined (reading zip)' hit 27 sessions on /checkout in the last 7 days, and Stripe logged 27 failed payments in the last 30 days. Zip is the field Stripe's AVS check reads, so a client-side crash reading that property could be silently breaking address verification before the charge is even attempted, turning a code bug into lost revenue that looks like a card decline. Add the Stripe payment_intent id to the client error log for this exception so the two data sets can be joined directly, then fix the null check on the zip field before it reaches the payment step.
evidence: target=/checkout sources=["own_telemetry","stripe"] js_error_path=/checkout js_error_sessions=27 stripe_failed_payments_30d=27 stripe_active_subscriptions=412
securityseverity: highfrom GitHub + own_telemetryAI
Checkout crash likely traces to the payment form's vulnerable validation library
GitHub flags a high-severity prototype-pollution vulnerability in the payment form's validation library, and in the same week telemetry shows a JS crash reading an undefined 'zip' property hitting 29 of the 36 sessions that reach /checkout. Prototype pollution corrupts object shape in exactly the way that produces 'reading undefined property' errors on form fields like zip. This is not just a stability bug, it is a live vulnerability actively misbehaving in the checkout path that handles payment data. Patch the validation library first among the three high-severity Dependabot alerts and confirm the zip error disappears with it.
evidence: target=acme/storefront sources=["github","own_telemetry"] dependabot_high_note=prototype-pollution issue in the payment form's validation library checkout_error_sessions=29 checkout_total_sessions=36
growthseverity: high/checkoutfrom Plausible Analytics + StripeAI
The checkout crash sits between a healthy funnel and $44.70 average revenue per subscriber
Own telemetry shows 70 sessions reach /cart but only 37 reach /checkout, and of those 37, 30 hit the zip-code JS crash before they can complete an order - meanwhile Stripe shows the business already carries 412 active subscriptions at $44.70 average revenue each. Every session that crashes at checkout is a visitor who got all the way through product discovery and cart only to fail at the last step, which is the most expensive place in the funnel to lose someone. This is not the same as the 27 failed payments Stripe logs, since those are card declines on requests that reached Stripe - this is failure before the charge is ever attempted. Fixing the zip-code error is likely the single highest-leverage checkout fix available given how far downstream in the funnel it sits.
evidence: target=/checkout sources=["plausible","stripe"] arpu_usd=44.7 cart_sessions=70 checkout_sessions=37 active_subscriptions=412 checkout_error_sessions=30
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-07-27 and 2026-07-29, 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-07-27T04:24:01.063Z 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-07-27 and 2026-07-29, 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-07-27T04:24:01.063Z sources=["pagespeed"] changePct=69
bugseverity: high/accountrules
JS error hitting 11 sessions: Failed to fetch orders: 503 Service Unavailable
"Failed to fetch orders: 503 Service Unavailable" fired 16 times across 11 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=11 occurrences=16
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-07-27 and 2026-07-29, 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-07-27T04:24:01.063Z movedTo=41 category=performance strategy=mobile changePct=40 movedFrom=68
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
seoseverity: medium/productsfrom Plausible Analytics + Site audit + own_telemetryAI
/products is the site's biggest entry point yet has no meta description and a live JS error
Plausible shows /products is the top entry page at 610 sessions and own telemetry confirms it is the single most-viewed page at 189 views this week, but site_audit finds no meta description on that URL and telemetry logs a JS error ('undefined is not an object, evaluating p.variants.length') affecting 9 sessions on the same page. Google is writing its own snippet for the page that brings in the most new visitors, and a fraction of those visitors then hit a script error before they can even browse products. Next action: fix the variants-length crash first since it blocks browsing, then write a meta description for /products since it is the highest-traffic page to lack one.
evidence: target=/products sources=["plausible","site_audit","own_telemetry"] page_views=189 entry_sessions=610 variants_error_sessions=9 meta_description_present=false
ideaseverity: mediumfrom GitHub + PageSpeed Insights + Site auditAI
Add a performance and accessibility budget to the CI pipeline that is already failing 34% of the time
The pipeline already fails on a third of runs, largely around checkout, while separately the product page ships 2,400ms of unused JavaScript, 5 render-blocking tags, and a Lighthouse performance score of 41. Rather than treating CI health and page performance as unrelated, use the fact that the pipeline is already a gate: add a Lighthouse CI budget check (LCP, unused JS, render-blocking count) as a required status alongside the integration tests, so regressions like the 1.9MB hero image or the 402KB of unused JS cannot merge in the first place. Next action: wire pagespeed's own opportunity metrics into a CI budget step with the current failing suite, since the failure culture is already there and just needs a performance dimension added to it.
evidence: target=acme/storefront sources=["github","pagespeed","site_audit"] unused_js_ms=2400 ci_fail_rate_pct=34 render_blocking_tags=5 lighthouse_perf_score=41
ideaseverity: medium/checkoutfrom GitHub + Site auditAI
Bundle every checkout fault into one hardening sprint instead of five separate tickets
Checkout alone accounts for a CI suite that fails most often (34% overall failure rate concentrated there), a crash hitting 23 of 38 sessions, 4 form fields with no label, a session cookie missing SameSite, and a site with no CSP header - five different sources pointing at one low-traffic template. Fixing these one at a time means touching the same checkout form markup five separate times; a single scoped sprint that adds labels, SameSite, and CSP in the same PR that fixes the zip crash removes the overlap and gives the CI suite a real regression test to gate on. Freeze non-critical checkout changes until that PR merges and the integration suite is green.
evidence: target=/checkout sources=["github","site_audit"] unlabeled_fields=4 checkout_sessions=38 ci_failure_rate_pct=34 checkout_crash_sessions=23
growthseverity: mediumrules
Roughly 85% of your visitors never reach client-side analytics
Plausible counted 2,140 visitors over the last 7 days; our in-browser SDK saw 329 sessions. One measures server-side and the other inside the page, so the difference is mostly ad blockers, Do Not Track and privacy browsers. 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: coveragePct=15 sdkSessions7d=329 plausibleVisitors7d=2140
bugseverity: high/productsrules
JS error hitting 9 sessions: undefined is not an object (evaluating 'p.variants.length')
"undefined is not an object (evaluating 'p.variants.length')" fired 13 times across 9 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=9 occurrences=13
pricingseverity: mediumfrom Stripe + Plausible AnalyticsAI
The $149 Scale plan has zero subscribers while Starter and Growth both fill out normally
Starter at $19 has 244 subscribers and Growth at $49 has 168, but Scale at $149 has exactly 0, despite the site drawing 2,140 unique visitors in the week measured. A gap that clean across three tiers is rarely a demand problem alone, it usually means the jump from $49 to $149 is priced or packaged wrong, or Scale is not being surfaced to the visitors who would need it. Next action: pull the Stripe checkout funnel by plan to see if anyone is even reaching the Scale price page, then test either a mid-tier price point or clearer differentiation copy for it.
evidence: target=pricing sources=["stripe","plausible"] scale_subscribers=0 growth_subscribers=168 starter_subscribers=244 weekly_unique_visitors=2140
growthseverity: mediumfrom PageSpeed Insights + Plausible AnalyticsAI
Real-user LCP of 5.4s on the homepage lines up with a 61% site-wide bounce rate
PageSpeed's field data (CrUX) puts homepage LCP at 5,400ms for real Chrome users, far slower than the 3,100ms lab figure, while Plausible shows a 61% bounce rate across the site and /products alone accounts for 610 entries. Users arriving from Google's 780 referred sessions are landing on pages that take over five seconds to show a meaningful paint before they can even decide whether to browse, which is a plausible driver of visitors leaving without a second pageview (2.4 pages per visit site-wide). Because /products and / together account for the majority of top-page traffic, prioritize the render-blocking and image-weight fixes on those two templates specifically, not just the product detail page, since that is where the bulk of first impressions happen.
evidence: target=https://shop.acme-demo.example sources=["pagespeed","plausible"] lab_lcp_ms=3100 bounce_rate=61 crux_lcp_ms=5400 pages_per_visit=2.4 products_entries=610
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: high/product/aurora-lamprules
Clicking "Size chart" on /product/aurora-lamp does nothing
11 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. 18 dead clicks in 7 days.
evidence: clicks=18 selector=div.pdp-specs>span.size-chart sessions=11 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"]
performanceseverity: high/product/aurora-lamprules
/product/aurora-lamp is slow: LCP p75 is 6090ms
The 75th percentile LCP on /product/aurora-lamp is 6090ms over 80 samples (7 days). Google rates LCP above 4000ms as "poor". Check hero image size, render-blocking scripts, and server response time.
evidence: p75=6090 metric=LCP samples=80
uxseverity: medium/checkoutrules
Users rage-click "Place order" on /checkout
8 different sessions rapidly clicked the same element (button#place-order) 14 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=14 selector=button#place-order sessions=8 windowDays=7
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
performanceseverity: high/product/nomad-backpackrules
/product/nomad-backpack is slow: LCP p75 is 5635ms
The 75th percentile LCP on /product/nomad-backpack is 5635ms over 34 samples (7 days). Google rates LCP above 4000ms as "poor". Check hero image size, render-blocking scripts, and server response time.
evidence: p75=5635 metric=LCP samples=34
performanceseverity: high/cartrules
/cart is slow: INP p75 is 598ms
The 75th percentile INP on /cart is 598ms over 26 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=598 metric=INP samples=26
functionalseverity: medium/product/nomad-backpackrules
Clicking "Only 3 left" on /product/nomad-backpack does nothing
6 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. 11 dead clicks in 7 days.
evidence: clicks=11 selector=div.pdp-buy>span.stock-badge sessions=6 windowDays=7
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}]
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 3234ms
The 75th percentile LCP on /checkout is 3234ms 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=3234 metric=LCP samples=26
productseverity: medium/accountrules
83% of visitors leave /account without going anywhere
10 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=10 sessions=12 bounceRate=0.83