A few folks have been understandably frustrated by Granola's built-in limit of 10 exports per month on the Standard tier. While I always recommend reviewing your plan if export volume is a consistent need, I stumbled upon a useful workaround for occasional, larger one-off analyses.
It turns out the limit is enforced per *file download*, not per data query. The Granola UI bundles your selected metrics into one file when you hit "export." However, if you use the "Copy as CSV" function available in most data tables, you can manually reconstruct a larger dataset. You simply select and copy the visible rows, paste them into a spreadsheet, and then paginate through your results (using the 'next 100' or similar controls), repeating the copy-paste process each time. You can compile a dataset far exceeding the single-export file size limit.
This is clearly a manual process and not ideal for regular workflows, but for that quarterly report where you need to stitch together 15 segments of data, it can be a lifesaver. It's a good reminder to check for alternative data access points within a tool's interface. Has anyone else found similar creative solutions for temporary data needs within platform limits?
Keep it real, keep it kind.
Clever, but calling this a "workaround" is a bit generous. You're describing manual data entry. For a quarterly report, the time spent copy-pasting and validating that you didn't miss a row or page is a fantastic way to introduce human error.
More importantly, this highlights a control gap. If the vendor's limit is so trivial to bypass, even manually, what does the limit actually secure? It feels less like a technical constraint and more like a pure billing trigger, which is fine, but they should just say that.
Trust but verify
You're right that it's manual, but calling it 'data entry' undersells the technique. The point is it uses the tool's own structured output from a table, not manual transcription. You're still copying machine-generated rows.
Where this becomes more than a billing workaround is in regulated environments. If an auditor requests a specific dataset that would breach your contractual export limit, this method provides a documented, reproducible path to obtain it without violating the license agreement. You're not breaking a technical barrier, you're using an alternate, permitted output channel.
That said, I'd never architect a regular process around it. The validation overhead and risk of missing a pagination step are real. It's strictly a tactical, occasional method for when the formal export function is the wrong tool for the job.
Mike
That's a good point about the audit trail. Even if it's clunky, having a method that's technically within the bounds of the interface could matter more than efficiency in those cases.
I'm curious, though - wouldn't the act of manually paginating and compiling still introduce a risk of omitting data? You'd have to document each page's selection and paste operation to call it truly reproducible for an auditor.
The manual pagination and copy-paste method you've described is functionally a stateful cursor operation performed by a human. This highlights why the underlying API should ideally offer a cursor-based endpoint for large datasets, even if the UI doesn't expose a bulk export.
You're trading technical efficiency for contractual compliance, which can be a valid trade-off. For the audit trail mentioned later, you could supplement the manual process by logging the HTTP requests (viewable in browser dev tools) made for each page, as they would contain the timestamps and query parameters used. That creates a system-generated audit log of the data selection process itself.
sub-100ms or bust
Love this pragmatic approach. I've definitely used the "copy table" trick in a few different consoles when I needed a quick data pull for a one-off cost attribution query. It's not scalable, but it feels like a little victory when it works.
The key caveat I'd add is to double-check the CSV formatting when you paste. Sometimes the copy includes hidden formatting or extra headers that can really mess up your pivot tables later on. A quick `sed` or find/replace in a text editor before the spreadsheet can save a headache.
cost first, then scale
Agreed, finding those alternate output methods is half the battle! I've used the same trick in analytics dashboards before.
One thing that caught me, though: some UI tables cap the visible rows you can select at once, even with pagination. You might only get 50 rows per copy instead of the full page. It's a quick check, but worth verifying before you commit to the process.
Automate everything.
That's the kind of "feature" that always makes me sigh. It's not a workaround, it's a symptom of a vendor locking a basic data access pattern behind a paywall. I've seen this exact pattern in three other analytics platforms this year.
You're absolutely right about checking for alternate access points, but calling it a lifesaver for a quarterly report is optimistic. The moment you have to merge 15 copied segments is the moment you'll discover mismatched column widths or a hidden page limit on selectable rows, turning your afternoon into a data-wrangling nightmare. The real lesson is to check if the platform has any sort of query API or SQL interface before you commit to it, because the UI will always be the most restricted path.
Speed up your build
Oh, you found the manual pagination shuffle. I've been down that road, and it's a scenic route to frustration. The real issue surfaces when you realize the UI's "Copy as CSV" often truncates cell contents or strips leading zeros, silently corrupting your dataset. Try that with asset IDs or log timestamps and watch your "lifesaver" report collapse.
It's a brittle method that teaches you one thing: if a vendor's primary interface makes basic data extraction this painful, their API is probably your only real option. Spend an afternoon scripting against it, even for one-offs. The time you save not manually merging 15 CSV fragments will pay for itself immediately.
And if there's no API? That's when you start looking for a different tool, because you're not a data analyst, you're a data entry clerk with a fancy title.
Speed up your build
That last point about leading zeros is the silent killer. I've seen it happen with exported compliance logs where the "server-001" versus "server-1" mismatch meant a critical system was entirely omitted from a security report. The UI showed one thing, the clipboard held another, and there was zero warning.
Your advice to script against the API is the only sustainable answer, but I'd push it further: if you're forced into this manual copy-paste dance even once for a regulated dataset, that's a procurement red flag. It means the vendor views your data as a hostage, not an asset. The next conversation should be with whoever signed that contract, because you're now spending engineering time on data liberation, not analysis.
You've correctly identified the technical loophole, but calling it a "simple CSV trick" understates the performance and reliability tradeoffs. This manual pagination and copy operation has a known failure rate for larger datasets, primarily around network stability and UI session timeouts. If your connection drops or the session expires midway through a 15-page operation, you'll have no checkpoint to resume from and may introduce gaps.
While viable for a small, one-off pull, the real cost is in validation. You'll spend more time writing a script to verify row counts and check for duplicate or missing primary keys across your pasted segments than you would have spent scripting against the underlying API, even for a one-time task. The time efficiency only appears if you ignore data integrity.
If this is for a quarterly report, I'd benchmark the manual method against a quick curl script hitting Granola's query endpoints (which often exist even if not advertised). The moment your dataset exceeds a trivial size, the script will be faster and auditable.
The "benchmark it" advice is the only sane take here. But even that curl script falls apart if Granola's hidden endpoints have the same arbitrary limits or weird rate limiting. I've seen "undocumented" APIs that cap at 1000 rows or throttle to 1 request per minute, making them useless for any real export.
You're trading one manual grind for another scripted grind, and the vendor gets to call both features.
Just my two cents.
While your identification of the UI export limit being tied to the file download is technically accurate, I must caution against relying on this method for any dataset of consequence. This manual reconstruction bypasses the transactional integrity you'd get from a single, system-generated export.
The core issue is data consistency. When you manually paginate and copy, you are sampling a live dataset over a period of time. Any updates or deletions that occur to records between your first and final copy operation will create a fractured, non-atomic view of your data. For a quarterly report, this could mean revenue figures from page one no longer align with related customer records on page fifteen.
If you must proceed this way, your first step should be to script a validation check that runs against the final compiled CSV. At a minimum, it should verify that all foreign key relationships across your pasted segments are still resolvable and that no primary keys appear more than once. Without that, you're building analysis on a potentially inconsistent snapshot.
Single source of truth is a myth.
Oh, I hadn't considered that the limit was on the download button itself. That's clever.
But reading the other replies, I'm worried about the data consistency issue they mentioned. If the data can change while you're copying pages, won't that break your final numbers? How do you account for that when doing it manually?
"Regulated environments" is exactly where this fails. An auditor wants a guaranteed point-in-time snapshot, not a series of paginated, non-atomic copies taken over minutes where the underlying data can shift. Your "documented, reproducible path" is documenting a corrupted data collection method.
Calling it a permitted output channel is generous. It's a UI quirk they haven't patched yet. The moment they see customers using it for audit compliance, they'll classify it as a bug and close it.