How to Schedule a Jira Export to Google Sheets

Start with a report-shaped JQL query

Use the narrowest query that answers the reporting question. Include a stable project or team boundary, explicit statuses, and an ORDER BY clause so refreshes are predictable. If you already have a saved filter that does this, see syncing a Jira filter to Google Sheets automatically for running it directly instead of rebuilding the query from scratch.

Test the JQL in Jira first. A scheduled export should automate a known-good query, not hide an uncertain one.

Choose columns before scheduling

1. Add the identifiers people use to verify a row: issue key, summary, status, assignee, and updated date.
2. Add only the custom fields needed by the report.
3. Keep the issue key as the stable row identity if the sheet may later feed an update workflow.

Run one manual refresh and check field formatting, permissions, and the expected issue count.

Set a useful cadence

Hourly works for operational queues, daily for team reporting, and weekly for planning snapshots. Schedule the report only after the manual result is correct, then keep formulas and dashboards on separate tabs so refreshes cannot overwrite them.

What a "schedule" actually has to do under the hood

A scheduled Jira export isn't just a saved query with a timer attached. Apps Script caps installable triggers at 20 per user per script, so a workable implementation shares a single hourly dispatcher across every saved query in the spreadsheet rather than creating one trigger per report. Each tick checks which queries are due and runs them; a query due hourly runs every tick, a daily one runs on the tick that crosses into its target hour, and so on. Because the query itself runs against Jira's current search endpoint, POST /rest/api/3/search/jql, paged with a continuation token rather than the older offset-based /search endpoint Atlassian has deprecated, a large result set can't be fetched in one call. The scheduler has to persist its paging cursor between chunks so a query that takes longer than one execution window resumes instead of restarting from page one.

Worked example: an hourly support queue report

A JQL query like project = SUP AND status != Done ORDER BY updated DESC against an active support project might return 40-60 open issues at any hour. Scheduled hourly with columns for issue key, summary, status, assignee, and updated date, the tab looks the same every time it refreshes, just current: closed issues drop off, new ones appear at the top by their updated date, and the issue key stays a stable anchor if anyone builds a lookup formula against a specific row elsewhere in the workbook.

Troubleshooting

The schedule doesn't seem to be firing

Check the spreadsheet's own Apps Script triggers list for a single shared hourly trigger, rather than looking for one trigger per saved query; if that shared trigger was deleted or the last schedule was switched back to manual, it won't exist at all.

A row shows a "partial" or truncated warning

That usually means the query hit a free-tier row cap partway through. The fix is upgrading the plan or narrowing the JQL so the result set fits, not re-running the same query and expecting a different row count.

The refreshed tab is missing issues I can see in Jira

Confirm the connected account's Jira permissions actually cover every project the JQL touches; a search API call only returns issues the authenticated user can see, silently omitting the rest rather than erroring.

Setting the schedule in practice

Sheet Sync for Jira adds one item under Extensions → Sheet Sync for Jira. Each saved import has a Refresh field with four options: Manual only, Every hour, Daily, and Weekly (Mondays). On the free plan every option past Manual only shows a lock with the message "Scheduled refresh is a Pro feature", so the choice to automate is explicit rather than something that silently degrades. Saving an import with a schedule other than manual is what creates the shared hourly trigger described above; switching every import back to manual removes it again, so there's nothing left running in the background once nothing needs it.

Manual export vs. a scheduled add-on

A manual export is a menu click and a known result, right up until someone forgets to re-run it before a Monday report. Building the trigger yourself means owning the Apps Script quota, the pagination cursor, and the custom-field flattening described above. Sheet Sync for Jira's honest tradeoff is the free plan's 500-row cap and manual-only refresh, which is enough to prove the report is right before paying to automate it; Pro removes both limits for the same saved query, no rebuild required.

Check custom fields before you schedule

A schedule just repeats whatever the manual run produced. If that run includes user, option, array, or rich-text custom fields, see why Jira custom fields export as [object Object] or raw JSON so a broken column doesn't refresh broken forever.