get_job_status

Cost: Free (0 credits).

get_job_status reports on an asynchronous job — such as a crawl_site run — by its job_id. It is how you follow an async tool from queued to succeeded (or failed).

What it does

Looks up the job under your account and returns its current status, its lifecycle timestamps, how long it has taken, and — once it succeeds — a short summary of the result. A job that does not belong to you is reported as not found, the same as an unknown id. It is not crawl-only: a pull_gsc_data job is summarized here too, and which summary you get is decided by the shape of the stored result, not by the tool's name.

A running job says how far it has got

While a crawl is running, each poll reports the pages crawled and skipped so far, with the moment that count was taken. Before this, every poll of a 90-second job returned the same string, so a job that was working and a job that was stuck looked exactly alike — and the only way to tell them apart was to wait and find out.

Every status line also carries a duration. When a job's stored timestamps contradict each other, the line says timing unavailable rather than printing a figure; a negative or impossible duration is not a measurement, and rows written before that was fixed still exist.

Which site, and what to do next

Every reply names the project the job ran against — by DOMAIN, in the same clause and the same words list_jobs uses, so the list you came from and the detail you asked for cannot describe one job two ways. A job with no project scope says so, and a project you have since removed falls back to the id it was recorded with.

A finished job ends with the step that follows it: a crawl points at the audits that read it, a Search Console pull at the tools that read a pull. A failed job says how to retry and where to go if it keeps failing. A job whose tool has no follow-up routed for it says nothing rather than guessing one — a suggestion that cannot read the result is worse than none.

Example

After crawl_site gives you a job_id, ask your MCP client:

What's the status of job <job_id>?

Repeat until the status is succeeded. A finished crawl summarizes how many pages were crawled, how many were skipped, and how many issues were found.

Input

Returns

The job status (queued, running, succeeded, or failed), its created / started / finished timestamps and elapsed time, which of your sites it ran against, a live page count while a crawl runs, and — on success — a result summary, or the error message on failure. A crawl summary also names the dominant reason pages were skipped, and says outright when the homepage was among them: "0 issues found" must not be readable as "clean" while the homepage never got fetched. A finished or failed job also ends with the step that follows it. A job you cannot reach — an unknown job_id or somebody else's — comes back as an error, not as an empty answer.