Lighthouse accessibility data unavailable

What this check does

Reports that the audit couldn’t fetch Lighthouse accessibility data from Google’s PageSpeed Insights (PSI) API. Without it, the Lighthouse accessibility score and several rule-level audits (color contrast, axe rule failures) couldn’t run, so the accessibility module reports a partial result based only on the static-HTML checks MetricSpot performs locally.

Why it matters

This isn’t a problem with your site — it’s a problem with the audit run. Five things commonly cause it:

• No PSI API key configured. Self-hosted MetricSpot installs need GOOGLE_PSI_KEY set; without one, the public PSI endpoint rate-limits aggressively.
• PSI quota exhausted. The free tier is 25,000 requests/day per key, 400/minute. A self-hosted instance running many audits in a short window hits the burst limit.
• Your page blocks headless Chrome. Some sites use Cloudflare Bot Fight Mode or a custom WAF that flags the PSI Chrome user-agent and returns a 403.
• The page is behind a login. PSI hits the URL anonymously. If the auditable content lives behind authentication, the public PSI render sees the login screen, not the real page.
• The page is unreachable from Google’s network. Geo-blocking, IP allowlists, internal-only DNS — any of these stop PSI from fetching the URL.

A “Lighthouse unavailable” finding for one audit is usually a transient PSI hiccup. Repeated occurrences across audits point at one of the above.

How to fix it

If you’re running MetricSpot self-hosted:

# Get a key: https://developers.google.com/speed/docs/insights/v5/get-started
echo "GOOGLE_PSI_KEY=AIza…" >> .env
# Restart the worker
dokku ps:restart metricspot

Without a key, PSI lets you make ~1 request per minute, anonymously. With a key, you get 25,000/day.

If you’re on managed MetricSpot (app.metricspot.com) — quota is already configured. A “Lighthouse unavailable” finding here means PSI itself failed on this URL. Try:

1. Re-run the audit. PSI returns transient 500s about 1% of the time.
2. Audit a public, unauthenticated URL. Confirm the page is reachable without a session cookie.
3. Check your WAF / bot rules. If you use Cloudflare, add the PSI user-agent to your allowlist. PSI declares itself as Chrome-Lighthouse.
4. Reproduce on the public PSI tool — if the public tool also fails on your URL, the issue is reproducible and not specific to MetricSpot.

For pages that genuinely cannot be PSI-audited (admin dashboards, customer-only areas), the rest of MetricSpot’s accessibility module still runs against the HTML we can fetch — alt text, form labels, lang attribute, descriptive link text, heading hierarchy, landmarks. Those static checks are the bulk of WCAG conformance anyway. PSI gives you the dynamic Lighthouse score on top.

Frequently asked questions

What’s the difference between this finding and “Lighthouse accessibility score”?

Lighthouse accessibility score fires when the score is below the threshold. This finding fires when PSI didn’t return a score at all. They’re mutually exclusive — you’ll see one or the other, not both.

Can I disable PSI and just use the static checks?

You can — set GOOGLE_PSI_KEY= empty and MetricSpot skips PSI entirely. You lose the Lighthouse score, the axe-core dynamic checks, and Core Web Vitals from the lab data. Most users keep PSI on.

Does this affect my overall audit score?

The accessibility module weighting accounts for missing PSI data — your overall score is computed from the checks that did run, not penalized for the missing ones. Fixing the underlying cause (WAF allowlist, login wall) lets the dynamic checks contribute next time.