Pull Jira Issue Status into Google Sheets

Two native ways to get a status column

The Issue Navigator's CSV/Excel export includes a Status column by default, already rendered as text like "In Progress" or "Done". It's a one-off download: opening the export dialog again re-runs it from scratch, and nothing about the result refreshes on its own. The other route is Atlassian's own Jira Cloud for Sheets add-on, which imports a JQL query or a starred filter directly into a spreadsheet. Per Atlassian's own documentation, that import runs through a "Get data from Jira" action or a JIRA() cell function, both triggered on demand, not on a schedule.

Neither one refreshes by itself

That's the gap most searches for this land on: a status column is achievable in two clicks, but keeping it current means someone re-running the export or re-triggering the JIRA() pull every time the sheet needs to be accurate. Jira Cloud for Sheets is also Jira Cloud-only and, per Atlassian's documentation, works reliably up to roughly 10,000 work items before you need to paginate the custom function manually with an offset.

If you're pulling status from the API directly

Anyone building this against the REST API rather than a spreadsheet add-on hits a second problem: status isn't a plain string in the response. Jira's own API documentation returns it as a nested object with an id, a name, and a statusCategory, the same shape as other system fields like issue type, priority, and resolution. A script that writes that object straight into a cell prints the raw JSON or [object Object] instead of "In Progress"; it has to read .name out of it first. See why Jira custom fields export as raw JSON for the same shape of problem across the rest of a typical field set.

What the raw field actually looks like

A single issue's status field in a Jira Cloud REST API response looks roughly like this:

"status": { "id": "3", "name": "In Progress", "statusCategory": { "id": 4, "key": "indeterminate", "name": "In Progress" } }

The value worth writing into a sheet cell is status.name. statusCategory is a separate, coarser grouping (Jira buckets every workflow status into "To Do", "In Progress", or "Done" behind the scenes) that's genuinely useful for a report that wants to group a dozen custom statuses into three buckets without hardcoding every status name your team happens to use, but it's a different column with a different purpose, not a substitute for the specific status name.

Worked example

A pivot or COUNTIFS against the Status category column answers "how much is still open" across a team that uses ten different custom status names, without a lookup table mapping each one by hand.

Troubleshooting

The status column shows a number instead of text

That's status.id being written instead of status.name. The ID is stable across workflow renames but meaningless to read; if a report needs to survive a status being renamed in Jira, key off id internally but always display name.

Grouping by status makes an unreadable number of columns

Group by statusCategory.name instead of the raw status name when the report just needs "open vs. done," and reserve the specific status name for a detail view.

The three routes compared

Each of the three gets a readable status column onto a sheet. What differs is what happens after the first pull.

Setting up a status column that refreshes itself

Sheet Sync for Jira adds one item under Extensions → Sheet Sync for Jira. The first open asks for a Jira site URL, an Atlassian account email, and an API token from id.atlassian.com → Security → API tokens; that read-only token never gets written into the spreadsheet. A new import then picks a JQL query or a saved filter, a field picker for status alongside issue key, summary, and assignee, and a destination tab that's created if missing and overwritten on every refresh. Status lands already flattened to its name, so there's no raw object to unpack and no .name lookup to write by hand. A JQL-sourced import has a Validate step that checks syntax and runs one real search against Jira before the import is saved, so a query that parses fine but can't actually return issues fails at setup instead of showing up later as a status column with no rows in it.

If the status needs to stay current across a whole filter

A status column is rarely the only thing a report needs; it's usually one column in a bigger JQL or saved-filter pull that also needs to keep itself up to date. See syncing a Jira filter to Google Sheets automatically for the scheduled version of this, or exporting more than 1,000 Jira issues if the filter is large enough to need paging past a single response.