Google Search Console's custom date range picker is rejecting any end date after December 31, 1969, blocking users from running custom performance queries as of October 13, 2026. The error message reads plainly: "Date can't be after 1969-12-31."

The bug affects the Performance report, the core dataset most site owners use to track clicks, impressions and query data. Standard preset ranges continue to function. Custom ranges do not.

Search Engine Roundtable's Barry Schwartz, who reported the issue, confirmed the failure on his own account and traced the first public report to a user named Punit on X, posting as @Punit6008 on October 13, 2026. Punit wrote: "Also I can see, Search console the END date shows 1970-01-01."

What exactly is broken?

The failure has a narrow, consistent shape. The default date selections work normally. Users can still pull data for:

• 24 hours
• 7 days
• 28 days
• 3 months
• 6 months
• 12 months
• 16 months

The break appears only when a user selects the custom date range option. The end date field then locks to a 1969 or 1970 boundary, and any attempt to move it forward triggers the rejection message. Schwartz reported the date stuck at 1969 on his account. Punit saw 1970-01-01 on his.

The discrepancy matters little in practice. Both values point to the same class of failure. The 1969 and 1970 dates are Unix epoch artifacts — timestamps at or near zero in Unix time, which counts seconds from January 1, 1970. Date picker bugs that surface these dates usually mean the interface received an empty, null or zeroed date value from the backend and rendered it literally.

That is tool-signal observation, not a confirmed Google statement. Google has not, at the time of reporting, acknowledged the bug or posted a status update. Takeaway: the interface is accepting presets and rejecting custom input, which points to a date-handling fault rather than a data outage.

Is the underlying data affected?

Nothing in the reports suggests data loss. The Performance report itself loads. Preset queries return results. Only the custom range control misbehaves. That separation indicates the bug sits in the picker component, not in the reporting pipeline behind it.

But this is inference from observed behavior, not a Google confirmation. Google has not said whether the fault is client-side, server-side or tied to a specific account tier. Users who need custom windows — a year-over-year comparison outside the 16-month preset, for example — currently have no workaround inside the product. Takeaway: data appears intact; access to custom slices of it does not.

Who does this hit hardest?

The impact concentrates on SEO practitioners and site owners who run non-standard comparisons. Agencies comparing campaign periods, publishers checking algorithm-update windows against exact dates, and analysts building reports on arbitrary ranges all lose that capability until the fix ships. Casual users relying on the 7-day or 28-day presets will notice nothing.

The timing is unhelpful. October sits inside the window where teams assemble quarterly reporting, and Google has run core updates in autumn periods before. Analysts who segment update impact by custom date boundaries lose their primary tool for that work. That is a workflow cost, not a ranking effect. Takeaway: the bug is an analyst's problem, not a rankings problem.

What to watch next

Monitor the Google Search Status Dashboard and the Search Central documentation for an acknowledgment. Watch the original X thread from Punit and the Search Engine Roundtable follow-up for confirmation that the picker accepts dates after 1969-12-31 again. If Google publishes a statement, expect it via the Search Central account rather than the product interface itself. Until then, treat custom-range figures from any automated GSC integration with caution — scripts calling the API may face the same date validation if the fault is server-side, though no report yet confirms that.

By Elena Vasquez, SERP Journal