How to Find Amazon QuickSight SPICE Ingestion Duration (IngestionTimeInSeconds) and Prevent Timeouts

Measure Amazon QuickSight SPICE dataset ingestion time via IngestionTimeInSeconds in list_ingestions; rank slow refreshes and reschedule to avoid timeouts

Tracking down Amazon QuickSight SPICE ingestion timeouts is frustrating when you can’t change the upstream job orchestration. If ingestion jobs are timing out and you need to move the heaviest datasets to off-peak windows, the practical question becomes simple: how long does each dataset’s ingestion actually take?

Problem in a nutshell

Ingestion errors were occurring due to dataset timeouts during SPICE ingestion. The ingestion triggers couldn’t be changed, so the goal was to identify which datasets were the slowest to upload and then reschedule those refreshes to quieter hours. Attempts to use list_ingestions, describe_ingestion, and list_refresh_schedules initially didn’t surface the actual duration. The search extended to whether CloudWatch could help, but the need was straightforward: start, end, or a single time delta for each ingestion.

Example that doesn’t surface duration

A common first pass is to list ingestions for a dataset and check their high-level status or metadata, which still leaves you without an explicit duration. A sketch like this doesn’t answer the “how long did it take?” question:

def scan_ingestions_no_timing(qs_api, ds_token):
    records = qs_api.list_ingestions(dataset=ds_token)
    for rec in records:
        # This prints that ingestions exist, but not their durations
        print("ingestion observed")

Even if you decorate it with more fields, you still won’t get the timing unless you explicitly read the value that represents duration.

What’s really going on

The key is already in the API result set you’re calling. The list_ingestions response contains the field IngestionTimeInSeconds. That value is exactly what you need to quantify how long each ingestion took.

Fix: pull IngestionTimeInSeconds and sort by the slowest

Query list_ingestions and extract IngestionTimeInSeconds. From there you can rank datasets by observed duration and shift the slowest ones to off-peak refresh windows.

def collect_ingestion_timings(qs_api, ds_token):
    data = qs_api.list_ingestions(dataset=ds_token)
    timing_rows = []
    for item in data:
        secs = item.get("IngestionTimeInSeconds")
        if secs is not None:
            timing_rows.append({"row": item, "seconds": secs})
    timing_rows.sort(key=lambda r: r["seconds"], reverse=True)
    return timing_rows
# Example usage
report = collect_ingestion_timings(qs_api=my_quicksight_client, ds_token=my_dataset_ref)
for entry in report:
    print(f"duration_seconds={entry['seconds']}")

This gives you a clear, deterministic way to identify the heaviest refreshes. No guessing, no manual correlation. Just read the field and act on it.

Why this matters

When SPICE ingestion timeouts cause failures, moving heavy ingestions out of peak hours is often the quickest mitigation available—especially if you can’t modify the infrastructure that triggers those jobs. Having a per-ingestion duration lets you choose the worst offenders first and reduce contention without changing the upstream pipeline.

Wrap-up

If you’re chasing ingestion timeouts in Amazon QuickSight and need to know which datasets are slow, the answer lives in the list_ingestions response: read IngestionTimeInSeconds. Use it to prioritize and reschedule heavy refreshes to off-peak windows, cutting down on failures and keeping dashboards healthy.