Google Search Incidents: Status, History & Fields

By William Zhu · Cofounder, InfiniSynapse · Published: 2026-09-08 · Last updated: 2026-09-24 · Last verified: 2026-09-24 · Reviewed by the InfiniSynapse Data Team.

Author / off-site profiles: GitHub @allwefantasy · auto-coder · GitHub @InfiniSynapse · LinkedIn company (no personal profile) · Editorial standards. No personal LinkedIn or vendor badge.

Reviewed by: InfiniSynapse Data Team · method review 2026-09-14. First-party reading of one public incident object and its sibling rows.

Trust / COI: About · Corrections. We sell SEO analysis workflows, so product references are a conflict of interest. The walkthrough below is a desk parse of a public incident page, not a customer Search Console export and not a ranking study.

Google Search incidents are the rows Google posts on the Search Status Dashboard. The live board shows whether an incident is open right now. History lists closed rows by product. One permalink is one incident. Copy product, severity, and notes from that page before a traffic dip becomes a ranking story.

TL;DR

A Google Search Status Dashboard incident page is a field sheet. It tells you which product Google named, which impact enum it attached, how severe it called the row, and what each status note said. It does not tell you which of your URLs moved.

Direct answer: Current Google Search incidents are on the live Search Status Dashboard. Past rows are on History, grouped as Crawling, Indexing, Ranking, and Serving. Open one permalink and copy product, impact, severity, begin, end, and every note before you open Search Console.

A 2026-09-14 curl of incidents.json returned HTTP 200, 12,961 bytes, and ten objects. This Google Search Status Dashboard guide uses that snapshot. Reproduce it with curl and json.loads. The derived hour counts are elapsed time, not impact scores.

What you will learn

• Which fields sit on one incident permalink
• How the March 2026 core row is worded in this feed
• Why impact, severity, and product outrank duration
• How serving rows differ from ranking rows
• Where this Google Search Status Dashboard reader stops

Where Google Search incidents are listed

Current Google Search incidents appear on the live dashboard. A board that says no incidents means nothing is posted as open at that refresh. Closed Google Search incidents stay on the history page. A single row lives at https://status.search.google.com/incidents/{id}. Google’s status dashboard documentation is the official description of that surface.

The 2026-09-14 desk fetch used in the sections below is a snapshot of incidents.json: HTTP 200, 12,961 bytes, ten objects. It is the reading copy for this page. It is not a live “open now” board. Refresh the dashboard when you need today’s status.

Active Google Search incidents versus history

The live board and the history page answer different questions. The live board answers whether Google has an incident posted as open. History answers which Google Search incidents already have a begin time, and often an end time, for each product.

A blank live board still leaves History intact. Mark the check as “no open incident at this refresh,” then read History if you need the last Ranking or Serving row. The status dashboard FAQ already says a missing row is not a certificate that ranking stood still.

Google Search incidents by product

In the 2026-09-14 snapshot, every object was Ranking or Serving. Crawling and Indexing had no object in that fetch. History still shows those product headings even when this snapshot is empty for them.

Keep the product Google printed. A Serving row stays a serving incident. A Ranking row stays a ranking incident, including core and spam updates.

What one incident page actually contains

Key definition: The Google Search Status Dashboard is Google’s public incident surface for Search. One permalink stores the official title, product, impact, severity, begin, end, and the updates[] notes. It is not a volatility calendar and it is not a property report.

Whether September 2026 has a ranking row is a retrieval question. The 2026-09-23 feed’s answer is on google algorithm updates september 2026: no confirmed ranking incident.

Google’s status dashboard documentation describes that surface as the place to check whether Search itself is listing an incident. A Google Search Status Dashboard reading should stay inside that claim. The page can say Ranking or Serving. It cannot say “your category lost clicks.”

The status dashboard FAQ is the official reminder that absence of a row is not a certificate of stillness. Keep that caveat next to every blank screenshot you file.

Paste the permalink into an InfiniSynapse Server API task workspace if you need a durable copy of the fields. That API layer stores the product, impact, and notes you already copied. It does not rewrite Google’s severity.

Product label versus site cause

Each 2026-09-14 object carried affected_products[] and a service_name. In this snapshot those values were Ranking or Serving. The Search technical requirements page is a separate official surface for crawl and index eligibility. It does not convert a Serving row into a ranking diagnosis.

A Google Search Status Dashboard reader who collapses those products will later blame a core window for a fifteen-minute outage.

Impact and severity are feed fields

status_impact and severity are observed enums. Eight of the ten rows are SERVICE_INFORMATION with severity: low. Two serving rows are SERVICE_DISRUPTION with severity: medium. Those labels describe Google’s service state. They do not prove a click change on any site.

The HTTP status code reference is a useful independent reminder that a retrieval code and a product impact are different jobs. HTTP 200 on incidents.json means the feed answered. It is not a ranking verdict.

March 2026 core: a field-by-field walk

The worked permalink is the March 2026 core update. On 2026-09-14 the feed object 7eTbAa2jWdToLkraZj5y still carried these fields. This is not a customer case. The sample size is one official object plus the nine siblings fetched the same morning.

The permalink fields we copied

RFC 3339 is the timestamp profile we used when converting begin and end to UTC hours. Offsets stay on the source fields. A Google Search Status Dashboard note that rounds this interval to “late March” will later manufacture overlap the feed never claimed.

Two update notes, 292 hours

json.loads on the 2026-09-14 bytes showed two notes, oldest last in the array:

1. 2026-03-27T09:14:16+00:00 — “Released the March 2026 core update. The rollout may take up to 2 weeks to complete.” Status: SERVICE_INFORMATION.
2. 2026-04-08T13:12:36+00:00 — “The rollout was complete as of April 8, 2026.” Status: AVAILABLE.

Store both. The completion note does not erase the release note. 292 hours is elapsed time. It does not prove that any URL moved, and a Google Search Status Dashboard briefing that treats “two weeks” as an impact score has left the page.

Read the two notes in order. The release sentence names the event and warns that rollout may take up to two weeks. The completion sentence only closes the window. A Google Search Status Dashboard archive that keeps only the April 8 line will later look like Google published a one-day core. It did not. The feed still shows begin on 27 March and end on 8 April.

The ranking systems guide is the official vocabulary list for ranking systems. It does not attach those systems to this permalink, and it does not name your queries.

Ten incidents observed on 2026-09-14

This is a first-party desk observation, not a customer result and not a market study. The sample size is the ten objects Google returned that morning. A later fetch can add, drop, or rewrite rows.

Hours are (end − begin) in UTC. Class labels such as core or spam are our words from external_desc, not a Google enum. None of those derived columns measure traffic. A Google Search Status Dashboard table that hides impact and severity will later treat every row as the same kind of event.

Figure: Two series from the same ten-row official feed. Count is how many rows sit in each class. Median hours is elapsed time inside that class. Neither series is impact.

Why impact, severity, and product come first

Duration is the easy number to screenshot. It is also the weakest. The August 2025 spam row ran 639 hours and stayed SERVICE_INFORMATION / low / Ranking. The 25 February 2026 serving row ran 0.2 hours and was SERVICE_DISRUPTION / medium / Serving. A Google Search Status Dashboard reader who sorts only by hours will call the spam row “bigger” and miss the only two medium disruptions in the snapshot.

The Search Status history page is the HTML twin of the feed. Keep the HTML title you saw and the machine fields you parsed. Later summaries tend to replace Google’s wording with a vendor nickname.

Reproduce the 2026-09-14 fetch

curl -sS -D - -o incidents-2026-09-14.json \
  https://status.search.google.com/incidents.json

A Google Search Status Dashboard archive should keep the response status, byte size, object count, and retrieval date beside the table. If a later poll returns eleven objects, add a retrieval line and leave the first table intact.

How long a Google Search incident lasts

Duration is (end − begin). It is elapsed time, not severity. In this snapshot the February 2026 serving row runs 0.2 hours (2026-02-25 03:55 to 04:10 UTC). The March 2026 core row runs 292 hours (2026-03-27 09:00 to 2026-04-08 13:00 UTC). The August 2025 spam row runs 639 hours and stays SERVICE_INFORMATION / low. Sort Google Search incidents by product and impact before you sort them by hours.

Google Search incidents and a traffic drop

A Google Search incidents row can share hours with a click drop. That overlap tells you which Search Console dates to open first. It does not name your URLs. Serving incidents can cut clicks while results fail to load. Ranking incidents are the core, spam, and Discover rows. After the fields are copied, continue with website traffic drop SEO and, when the product is Ranking, ranking drop after update.

How to read product, severity, and notes

The job on one Google Search Status Dashboard permalink is transcription, not storytelling. Open the page. Copy the four fields. Stop.

Do not translate Serving into Ranking

If affected_products says Serving, write Serving. Do not “helpfully” retitle the row as a core update because a traffic chart moved the same week. The February 2026 serving note said “Serving was experiencing an issue,” then “We fixed the issue with serving search results.” That wording is operational. A Google Search Status Dashboard file that files it under ranking has already failed the product test.

Append notes instead of overwriting them

The October 2025 serving row is the only object in this snapshot with three notes. The first mentioned a data-center issue that might affect some pages in some locales. The second said a fix was in progress. The third said the issue had resolved itself. If you keep only the last sentence, a later reviewer cannot see what Google claimed while the window was open.

Treat each updates[] item as append-only. That habit is what keeps a Google Search Status Dashboard reading replayable.

When the notes disagree with a social screenshot, keep the feed. Vendor blogs often collapse SERVICE_INFORMATION and SERVICE_DISRUPTION into one “incident” label. The Google Search Status Dashboard enums are the ones a later reviewer can reopen. If you need a human-readable twin, use the history page, not a third-party calendar.

Misreads that invent a ranking story

Treating every row as ranking

The warning sign is a slide that lists all ten titles under “algorithm updates.” Two of those titles are serving disruptions. The correction is to keep the product column visible on every Google Search Status Dashboard excerpt you publish.

Overwriting the first note

The warning sign is a completion screenshot standing in for the whole lifecycle. The March 2026 core completion note is one sentence. The release note is the sentence that named the event. Keep both.

Calling a blank dashboard an all-clear

The warning sign is “no row, so Google changed nothing.” The status dashboard FAQ already rejects that leap. Mark the day as no named incident found. A Google Search Status Dashboard screenshot cannot establish that ranking was frozen.

Limits of the public dashboard

Publication is selective

Google does not publish every ranking adjustment. A quiet day on the Google Search Status Dashboard means no named event was in the feed we fetched. It does not prove that smaller changes stopped. Publish that caveat beside the empty date.

The feed does not name URLs

The ten-row sample never lists affected URLs, industries, or queries. This snapshot is also not a customer result. We have no third-party GSC export attached to these dates. Anyone using a Google Search Status Dashboard row on a live property must replace the empty overlay with their own preserved filters.

A second reviewer should be able to open the same permalink and see the same product, impact, and severity. If they cannot, the Google Search Status Dashboard excerpt was rewritten. Restore the official wording before you discuss Search Console.

Where the incident reader stops

After the fields are copied, the next job is no longer this page. The google algorithm tracker is the register that admits the official URL and keeps the window. A website traffic drop SEO diagnosis then checks serving and measurement before any ranking hypothesis. A ranking drop after update comparison is the later overlay that uses matching Search Console segments. An incident row is not a blog post. The Search Central blog is the authored lane.

Frequently Asked Questions

Where do I see current Google Search incidents?

Open the live Search Status Dashboard. If it shows no incidents, nothing is posted as open at that refresh. Past Google Search incidents are on History, under Crawling, Indexing, Ranking, and Serving. One row’s fields are on its /incidents/{id} permalink.

Does low severity mean rankings did not move?

No. severity: low is Google’s service label on that Google Search Status Dashboard row. It is not a traffic score and it does not prove that positions were stable on your property.

What should I copy from an incident page first?

Copy the product, the impact enum, the severity, the begin and end timestamps, and every note in updates[]. Reproduce those fields from the permalink or from json.loads on the feed object. Do not start with a vendor nickname. Those five copies are the whole Google Search Status Dashboard job on day one.

Can the completion note end a Search Console review?

Use it as one boundary, then inspect adjacent days without relabeling them as rollout days. Completion ends the official window on the Google Search Status Dashboard. It does not close alternative causes.

Why does a Serving row look like a ranking problem?

Because users cannot reach results during a disruption, clicks can fall in the same hours. That coincidence does not turn Serving into Ranking. Keep the product the Google Search Status Dashboard published.

Conclusion

Use the Google Search Status Dashboard when the job is to read one official incident without translating it into a site story. The 2026-09-14 snapshot shows ten objects, two products, and a hard split between elapsed hours and impact. Close the reader when the product, the severity, the notes, and the unresolved alternatives are all still visible. A bounded Google Search Status Dashboard transcription is more useful than an unsupported recovery claim.

To inspect public results around a specific incident window, Google before date search and verify dates on each source.