What is the average latency for a Consumer Report, and how do I troubleshoot timeouts?

This article explains how Consumer Report generation latency works, what to expect under normal conditions, and how to avoid common causes of delays and timeouts.

Under typical conditions, CRA report generation has a P50 latency of about 10 seconds. This means about half of reports complete at or below 10 seconds in normal operation.

CRA report generation time depends on several factors in your flow and data. A frequent driver is how a user token is configured and used during report creation. If too many items are linked to a single user token, end-to-end processing can slow down and may eventually hit timeouts.

Best practices to minimize latency and avoid timeouts

Follow these guidelines to keep performance consistent and reduce the risk of timeouts:

• Keep your user token lean. Avoid linking an excessive number of items to the same token, especially in production flows where you need predictable performance.
• Request only the CRA products you need in a given flow. Unnecessary work increases processing time without adding value.
• In testing, prefer Plaid-provided sandbox users over large custom JSON payloads. Overstuffed custom users can simulate atypically large data sets that increase latency and cause timeouts.
• Monitor your application’s webhook handling. Use USER_CHECK_REPORT_READY to proceed when the report is finished and USER_CHECK_REPORT_FAILED to handle failures or retries gracefully. (Legacy integrations may still receive CHECK_REPORT_READY / CHECK_REPORT_FAILED; new integrations should listen for the USER_* variants.) This ensures a responsive user experience even when report generation takes longer than average.

Troubleshooting checklist

If you’re observing elevated latency or sporadic timeouts:

• Review how many items are linked to the affected user token; reduce where possible.
• Confirm you’re only generating the products required for the current use case.
• Re-test with Plaid’s standard sandbox users to rule out test data that’s unusually large or complex.
• Ensure your webhook and retry logic is robust so your app remains responsive while the report completes.