CrUX Pipeline Delays: What Late Field Data Means for Client Reports

CrUX field numbers in a client report carry two dates most teams never write on the slide: when Google published the aggregate, and which 28 days of Chrome sessions sit inside it. PageSpeed Insights, the CrUX API, CrUX Vis, Search Console, and BigQuery each refresh on a different schedule. Field Largest Contentful Paint and Interaction to Next Paint are always a rolling 28-day average on top of that schedule. Lab scores from a scheduled PageSpeed Insights run can turn green the morning after a deploy while the field band beside them stays amber for weeks. None of those contradictions mean the fix failed. They mean engineering, SEO, and the client are reading different clocks without labelling them.

Agencies lose retainer hours when those clocks get treated as one bug. Engineering trusts the lab trend; SEO trusts Search Console; the client trusts whichever PageSpeed Insights paste arrived in email first. Without a shared "field data as of" line, a routine CrUX pipeline delay reads like negligence. What follows separates pipeline lag (when Google publishes CrUX) from the 28-day rolling window (what CrUX averages once published), maps the Chrome UX Report update schedule across API, History, and BigQuery, and gives copy-ready footnotes for client-ready Core Web Vitals reports. For why a shipped fix can still sit inside a green lab run and an amber field band for weeks, see why your Core Web Vitals fix is not in CrUX yet. For where to read field history after the CrUX Dashboard retirement, see where to get TTFB, INP, and field history.

What CrUX data delay means for agency client reports

"CrUX data delay" shows up in two conversations that get mixed together in client Slack. The first is publication lag: Chrome User Experience Report (CrUX) data moves through Google's pipeline before it appears in PageSpeed Insights, the CrUX API, CrUX Vis, Search Console, or BigQuery. The second is rolling-window lag: even when publication is on time, field percentiles describe roughly the past 28 days of real Chrome sessions, so a Tuesday deploy cannot rewrite Friday's field screenshot.

Client reports go wrong when those two lags are treated as one bug. A PageSpeed Insights field section that still shows last week's collectionPeriod end date is often a short pipeline or API refresh issue, not proof that users are still suffering pre-fix timings. A field band that barely moves for three weeks after a large fix is usually the rolling window doing its job, not a broken pipeline. Your report should name which lag you are discussing before you paste a number.

Account managers do not need the full pipeline diagram. They need one sentence in the executive summary: field metrics are a rolling average of real-user Chrome data, refreshed on Google's schedule; lab metrics below are our same-week verification. That single line prevents most "your report is wrong" threads when CrUX is merely late, not wrong.

Chrome UX Report update schedule: daily API, weekly History, monthly BigQuery

Google publishes CrUX through several surfaces that update on different cadences. Teams that check only one surface often assume the whole ecosystem is broken. PageSpeed Insights field data and the daily CrUX API answer "what does field say this week?" CrUX History API and CrUX Vis answer "how has the trend moved over the past months?" BigQuery answers "what did the origin look like in March?" for analysts who accept monthly grain and query cost. Pick the surface that matches the question before you paste a number into a client deck.

According to Chrome's CrUX API documentation, the public dataset refreshes daily around 04:00 UTC on a best-effort basis with no fixed service-level agreement. Responses include a collectionPeriod with firstDate and endDate so you can see whether today's query returned a new aggregation window or the same window as yesterday. Chrome's docs also note that the API is typically about two days behind "today" in Pacific time, which is normal processing lag rather than a stalled deploy on your site.

The CrUX History API publishes weekly series: each point covers a 28-day window whose end dates are spaced seven days apart, with up to about 40 historical points. Weekly publication is aimed at trend charts in CrUX Vis and custom dashboards, not same-day deploy proof. CrUX on BigQuery releases on the second Tuesday of the month following each collection period, which is why BigQuery-only workflows feel like a month-long CrUX data delay even when PageSpeed Insights has already moved.

When you build a client-ready Core Web Vitals report outline, put daily or weekly field numbers in the scorecard and relegate BigQuery charts to appendix slides for analysts. Mixing monthly SQL exports into a weekly status email is how agencies accidentally tell a client their site regressed when PageSpeed Insights field data had already turned green.

Why CrUX pipeline delays happen beyond the rolling window

The 28-day rolling average is predictable. CrUX pipeline delays are the extra slips: processing backlog, holiday staffing, connector outages on legacy Looker paths, or incidents that delay a weekly History release while the daily API still updates. Google's CrUX release notes are the authoritative place to check whether a missing weekly point is your origin or the whole dataset. The May 2026 notes, for example, mention a slight delay to the weekly CrUX History API and CrUX Vis release that was resolved separately from the monthly BigQuery publish.

Pipeline incidents are not the same as "my fix did not work." During a History API slip, CrUX Vis may show a flat line for one week while PageSpeed Insights field sections still advance their collectionPeriod end date on schedule. During heavy monthly release weeks, teams that relied on the retired CrUX Dashboard connector sometimes saw monthly bars pause even though the API moved. After the CrUX Dashboard retirement, those connector failures are less common, but weekly and monthly surfaces still batch work differently than the daily API. A report that mixes a Monday lab run with a weekly History chart and no dates on either axis will look inconsistent even when Google published everything correctly.

Low-traffic URLs add a different kind of delay that looks like a pipeline fault. CrUX omits URL-level field data when sample sizes are too thin, and PageSpeed Insights may show origin-level field bands while the URL you changed stays empty. That "no data" state can persist across daily refreshes until enough Chrome sessions accumulate. It is eligibility and popularity filtering, not a stuck ETL job. Google's CrUX methodology documents discoverability and popularity rules. Your footnote should say URL-level field data not available; origin-level field shown when that is what the tool returned. Holiday weeks add the same confusion: a report drafted on the Tuesday after a long weekend may pair a fresh lab run with a History chart whose endDate still ends on the previous Saturday because the weekly job has not published yet.

In our experience, the CrUX Google Group threads that age badly inside agencies are the ones where nobody wrote down which surface was checked. Standardise on PageSpeed Insights or the daily API for current field and CrUX Vis for trend. When a weekly point is missing globally, link the release notes in the report caption so the client sees you checked for a pipeline slip rather than ignoring a regression.

How late CrUX field data affects client Core Web Vitals reports

Late field data changes the story in client reports even when engineering already closed the ticket. Checkout field Interaction to Next Paint can stay amber while the rolling window is only halfway through shedding pre-fix sessions. Origin field Largest Contentful Paint can look green while the product listing URL the client cares about never earns URL-level CrUX. A weekly trend chart can sit flat for one publication cycle because History API ran late, so leadership assumes performance work stalled. Each pattern needs its own sentence in the report, not a generic "CrUX is slow" disclaimer.

Search Console status badges trail the same CrUX base as PageSpeed Insights field data. A Needs improvement label in week one after a deploy is expected when the rolling window still contains mostly pre-fix traffic. Clients who treat Search Console as a real-time monitor will forward screenshots that contradict your lab appendix unless you date both artefacts and explain that Search Console updates on CrUX's schedule, not on deploy day.

Executive summaries that only cite field numbers make pipeline delays look like negligence. If the headline says mobile LCP is still 3.1s without field data through 9 Aug and lab homepage 2.3s on 12 Aug runs, the client will compare your PDF to their own PageSpeed Insights paste from a different collectionPeriod. Trust breaks fast. One dated footnote fixes most of that.

Trend slides built only from BigQuery or weekly History can miss a step change that daily PageSpeed Insights already shows in the collectionPeriod end date. Daily API checks without History miss slow drifts that only become obvious across six weekly points. Multi-site portfolios amplify the noise: one client's field data updates on schedule while another's URL never earns CrUX eligibility, and a portfolio table without per-row collection dates looks like you ignored a site when the pipeline returned no data legitimately.

The operational fix is to treat field metrics as dated lagging indicators in every client-facing table and lab metrics as scheduled verification with run timestamps. That split matches how we described lab versus field clocks in synthetic versus real user monitoring and in PageSpeed Insights versus automated monitoring. Field answers what Google will eventually show in search tooling. Lab answers whether your release is healthy on the URLs you monitor.

How to annotate client reports with field data collection dates

Every field number in a client report needs a collection window beside it. PageSpeed Insights has displayed collectionPeriod dates since late 2024; the CrUX API has exposed firstDate and endDate since 2022. If your report omits them, the client will supply their own assumed "as of today" date when they re-test.

Add these elements to the scorecard and executive summary from our client report template:

Executive summary footnote (copy-ready):

Field Core Web Vitals below are 75th-percentile values from Google's Chrome UX Report, averaged over a rolling 28-day window. Collection period: {firstDate} to {endDate} (source: PageSpeed Insights / CrUX API). Lab scores are scheduled PageSpeed Insights Lighthouse runs on {run dates} on the URLs listed in the appendix.

Scorecard column headers:

Trend chart caption:

Weekly points: CrUX History API (28-day windows ending Saturdays). If the latest weekly point is missing, check CrUX release notes for pipeline delays before interpreting a flat line.

When field and lab disagree, use a single explanatory line rather than a paragraph of theory:

Field LCP remains amber because CrUX still includes sessions from before the 4 Aug image fix. Lab LCP on the same URL has been below 2.5s on daily scheduled runs since 5 Aug. We expect field to follow as older sessions roll out of the window.

When CrUX returns no URL-level field data, state what you showed instead:

URL-level CrUX data is not available for /checkout (insufficient Chrome traffic). Origin-level mobile LCP is shown below; lab monitoring covers /checkout directly.

Account managers can paste those lines without opening the CrUX API. Technical leads should store firstDate, endDate, and lab run timestamps in the same spreadsheet or monitoring export you already use for multi-site portfolios, so the dates are not retyped by hand each month.

Use synthetic monitoring while CrUX field data is late

Pipeline lag and rolling-window lag both create a gap between deploy and field proof. Synthetic monitoring fills that gap with scheduled lab runs on the URLs you choose, on a clock you control. It does not replace CrUX for Search Console or PageSpeed Insights field reporting. It gives the client something credible to read while Google's publication schedule and 28-day average catch up.

A practical agency workflow during a CrUX delay week:

1. Baseline before change. Capture mobile and desktop lab LCP, INP, and CLS on priority URLs, with run dates stored alongside any field collectionPeriod you quote.
2. Increase schedule frequency on touched URLs for two weeks after deploy (daily or every two days on checkout and homepage, weekly on long tail), matching the priority model in how to schedule PageSpeed monitoring.
3. Set lab budgets and alerts so a regression during the wait still notifies someone, using thresholds from a shared performance budget template.
4. Check field once per week, not every morning. Note whether endDate moved and whether release notes mention a global History API delay.
5. Ship the client report with both clocks labelled. Lab trend proves the release; field dates prove you are not hiding behind a stale screenshot.

Apogee Watcher runs that split for multi-tenant teams: scheduled PageSpeed Insights-backed lab tests across many client sites, CrUX field numbers when Google returns them beside the same run, budgets and alerts while field data lags, and organisation-level views so agencies are not pasting PageSpeed Insights links into separate spreadsheets per client. We do not shorten Google's pipeline or replace first-party real-user monitoring. We give you a repeatable lab clock next to the field clock Google publishes, layered onto the SEO and observability tools you already use.

Start a free trial to schedule lab monitoring across your portfolio, or run a free PageSpeed check on a priority URL and compare the lab result to the field collectionPeriod on the same screen.

FAQ

How often does the CrUX API update?

The CrUX API refreshes daily around 04:00 UTC on a best-effort basis. Each response includes a collectionPeriod showing the 28-day window that was aggregated. The API is typically about two days behind the current calendar date in Pacific time. That processing lag is normal; compare today's endDate to yesterday's to see whether a new day entered the window.

What is the Chrome UX Report update schedule for History and BigQuery?

The CrUX History API publishes weekly series (28-day windows spaced seven days apart, up to about 40 points) for trend charts in CrUX Vis. BigQuery monthly tables release on the second Tuesday after each collection month. Use daily API or PageSpeed Insights field data for current scorecards; use History for trends; use BigQuery for long-range SQL analysis.

Is a CrUX pipeline delay the same as the 28-day rolling window?

No. The rolling window means field values always blend roughly the past 28 days of sessions, so fixes age in gradually. A pipeline delay means Google's publication job for a given surface (often weekly History or monthly BigQuery) ran late, so the tool shows an older collectionPeriod or missing weekly point even though daily PageSpeed Insights may already advanced. Check release notes when the whole ecosystem seems stuck on the same dates.

What should we tell clients when field data is late after a deploy?

Tell them you verified the fix in scheduled lab runs on specific URLs and dates, that CrUX field data is a 28-day average refreshed on Google's schedule, and quote the field collectionPeriod on the report. One dated footnote prevents the client from comparing your PDF to a PageSpeed Insights paste from a different window.

Should we pause client reports when CrUX History misses a week?

Do not pause reports if lab monitoring is healthy. Update the trend chart caption to note a possible pipeline delay, link release notes if Google announced a slip, and rely on daily field collectionPeriod dates or lab trends for the executive summary. Pause only if you have no lab history and no field dates to cite.

References

• CrUX API (Chrome for Developers)
• How to use the CrUX History API (Chrome for Developers)
• CrUX on BigQuery (Chrome for Developers)
• CrUX release notes (Chrome for Developers)
• CrUX methodology (Chrome for Developers)
• Why your Core Web Vitals fix is not in CrUX yet (28-day window) (Apogee Watcher)
• CrUX Dashboard retired: where to get TTFB, INP, and field history (Apogee Watcher)
• Client-ready Core Web Vitals report outline (Apogee Watcher)
• When to use synthetic vs real user monitoring for performance (Apogee Watcher)
• PageSpeed Insights vs automated monitoring (Apogee Watcher)
• How to schedule PageSpeed monitoring test frequency (Apogee Watcher)
• Performance budget thresholds template (Apogee Watcher)