Pulse docs

Overview

Pulse checks a page against Google's actual Core Web Vitals: field data from the Chrome UX Report (real Chrome users, a rolling 28-day window) and a single live Lighthouse lab run. Field data is what Google's search ranking signal actually uses. Lab data is what most site-owners have only ever looked at, a single synthetic run, useful for debugging a specific page load but not the same measurement as the ranking signal.

REST API

POST /api/check

curl -X POST https://pulse.allthepossibles.com/api/check \
  -H "content-type: application/json" \
  -d '{"url": "https://example.com"}'

Response is a CheckReport: vitals.field (real-user data, null when the origin doesn't have enough Chrome traffic yet, which is common and not a check failure), vitals.lab (this run's Lighthouse numbers), and passesCoreWebVitals (true only when all three field metrics rate "good", Google's actual bar, not an invented one).

Basic: higher rate limit

$5/mo. Raises the rate limit on /api/check and check_vitals to 150 checks/minute when a Basic key is passed as a Bearer token. That's the only thing Basic changes: no monitoring, no extra endpoints. Start Basic from the homepage, same Stripe Checkout flow as Pro. Useful for a CI pipeline or an agent that checks pages often enough to hit the free tier's 20/minute.

Pro: monitoring & alerts

$19/mo. Monitor up to 10 URLs, rechecked once daily, with an email the moment a page's verdict flips from passing to failing or any metric drops a rating tier (good to needs-improvement, or needs-improvement to poor). A transition to/from "unavailable" isn't treated as a regression, that's CrUX gaining or losing traffic data, not the page getting slower.

Start Pro from the homepage, Stripe Checkout, no card required up front unless Stripe needs one for your region. You get an API key back immediately and by email. (Checkout is a POST, not a plain link, on purpose, a bare GET link is something a crawler can trigger by just following it.)

POST /api/clients

curl -X POST https://pulse.allthepossibles.com/api/clients \
  -H "Authorization: Bearer <your key>" \
  -H "content-type: application/json" \
  -d '{"url": "https://example.com", "label": "optional name"}'

GET /api/clients lists everything you're monitoring. DELETE /api/clients/:id removes one. All three require a Pro key; a Basic key gets a 403, monitoring isn't something Basic unlocks at any rate limit.

Pro also raises the free-tier rate limit to 500 checks/minute on /api/check and check_vitals when the same key is passed.

MCP server

{
  "mcpServers": {
    "pulse": { "url": "https://pulse.allthepossibles.com/mcp" }
  }
}

check_vitals takes the same input shape as /api/check and returns the report as JSON text content.

The three metrics

These are Google's own published thresholds, not this product's opinion. INP replaced FID as the official responsiveness metric in March 2024, most competing tools and dashboards still quote the old one.

Rate limits

20 checks/minute per caller IP with no key, 150/minute with a Basic key, 500/minute with a Pro key, all tracked in D1. A 429 means you've hit it.

Known limitations

Field data legitimately doesn't exist for lower-traffic sites and pages, CrUX needs a real sample size before Google will report on an origin. That's not a broken check, it's an honest "not enough data yet." Lab data is a single Lighthouse run; treat it as directional; run-to-run variance on lab metrics is real and well-documented, not unique to this tool.

Monitoring compares each daily check against the single most recent prior check of that URL. A page that regresses and recovers between two daily runs (a bad deploy reverted within hours, say) won't trigger an alert, only what's true at check time each day is compared.

Support

Found a bug or a false reading: support@allthepossibles.com.

Managing a Pro subscription, invoices, payment method, cancellation: /billing. Checking how many checks a key has made this billing period: /usage, or GET /api/usage with the key as a Bearer token.