Integration•8 min read

Why Is My Celigo Integration Running Slowly? Common Causes and Fixes

Start by Finding Where the Time Goes

A slow Celigo integration can leave orders waiting, stock levels out of date, and teams checking records by hand. Possible causes include a busy connection queue, API limits, large exports, repeated lookups, and slow work in the destination app. The right fix depends on where the delay begins.

We conducted a documentation review of Celigo, Oracle NetSuite, and Shopify guidance to build this troubleshooting guide. Our analysis focuses on checks you can repeat in your own account. It is a review of published guidance, not a benchmark of customer systems.

First, separate the time before a scheduled run starts from the time spent processing records. For example, a flow scheduled every 30 minutes can leave a new order waiting even if the run itself takes only two minutes. Shortening that schedule will not fix a slow import step.

1. Check Whether Records Are Waiting in a Queue

Celigo says each connection has a first-in, first-out queue. Its Queue size column shows waiting messages, while the connection's concurrency setting controls how many messages can be processed at once. Flows sharing that connection also share its capacity.[1]

Watch the queue during a slow period. A growing queue suggests work is arriving faster than the connection can clear it. Compare that period with a quieter run before changing settings.

  • Record the flow name, run ID, start time, finish time, and record count.
  • Note which export, lookup, or import step takes longest.
  • Check other flows using the same connection at that time.
  • Save the error codes and recent mapping, script, or schedule changes.

If a bulk product update is delaying orders, consider moving that update to a quieter time. Choose a schedule that still meets the business need for fresh product data.

2. Match Concurrency to the API's Real Limits

More parallel work is useful only when the receiving app can accept it. Oracle states that NetSuite's account concurrency limit covers the combined total of web services and RESTlet requests. Other integrations can therefore use capacity that Celigo also needs.[2]

For a Shopify connection, the limit works differently. Shopify documents calculated query costs for its GraphQL Admin API and request-based limits for its REST Admin API. A connection setting that works for one API may not suit the other.[3]

Use the symptom to choose the next check
What you seeWhat to checkFirst change to test
Queue grows; few errorsShared flows and available API capacityMove a bulk job outside the busy window
Rate-limit or concurrency errorsEndpoint limits and competing clientsLower request pressure and review recovery settings
One export takes most of the runSearch filters, fields, and record volumeExport a smaller, relevant data set
Lookup time grows with record countRepeated calls for the same informationRemove one unnecessary lookup
Import is slow with a small queueDestination response times and record processingTrace a representative slow record

Start with the limit for your own account and API, then leave room for other clients. Adding connections does not raise the destination's account limit. Keep a record of the old values so you can reverse a change that increases errors.

3. Test Page Size Instead of Simply Making It Larger

Celigo splits exported records into pages. Its tuning guide explains that page size and connection concurrency work together: very large pages can leave too few pages to use the available parallel capacity. Very small pages can add processing overhead.[4]

For illustration, 1,000 records divided into pages of 1,000 creates one page. Pages of 100 create ten. This is an arithmetic example, not a promise of a tenfold speed increase. The endpoint, record size, and flow steps still affect the result.

Test a modest change with the same record mix. Include orders with many lines as well as simple records. Compare successful records per minute, errors, and total run time. Keep the change only if it improves the result without breaking record order or accuracy.

A Five-Step Path to the Right Fix

Use this sequence to avoid changing several settings at once. If the final check fails, return to the slow step and test another cause.

MeasureCapture run time, volume, queue size, and errors.
LocateFind the step where records wait longest.
Check limitsConfirm API capacity and competing work.
Test one fixUse a controlled batch and save old settings.
VerifyCompare speed, errors, and destination records.

4. Stop Moving Data You Do Not Need

Celigo's troubleshooting guidance recommends checking for unnecessary fields, files, whole catalogs, and extra searches. It also calls out the performance impact of choosing an All export instead of a Delta export.[5]

Review the business rule before reducing the data. If a flow only needs changed items, test a delta export where the connector supports it. Keep a clear first-load and recovery process so older records do not disappear from the sync by mistake.

For a saved search, compare its result count with the number of records the business expected. Remove unused columns and narrow filters carefully. Check timestamps, time zones, and the handling of late changes before relying on a smaller export window.

5. Review Repeated Lookups and Custom Logic

A lookup may seem minor until it runs for every order line. Celigo notes that lookup requests can run one at a time and that payload size can affect their speed.[5] Trace the slow step before assuming the whole platform needs more capacity.

  • Remove lookups whose results are no longer used.
  • Reuse stable reference data where supported, with a clear refresh rule.
  • Fetch only the fields the next step needs.
  • Review custom hooks for repeated work and large loops.
  • Test customer-before-order dependencies before running more work in parallel.

For example, if every line asks for the same warehouse code, check whether the flow can resolve it once at the right scope. Do not cache values that must reflect each transaction's current state.

6. Look Inside NetSuite When the Import Is Slow

Oracle's Concurrency Monitor provides an account overview and a details dashboard with minute-by-minute counts. It can help you compare the slow run's timing with concurrency pressure in NetSuite.[6]

If the account has spare capacity but one record type still takes longer, ask your NetSuite administrator to trace that record's processing. Review the searches, scripts, and workflows involved. Test any proposed change in a suitable test environment and check that required approvals and business rules still run.

Measure a comparable set of records at both quiet and busy times. This helps distinguish a flow design issue from a delay that appears only when several processes compete for the same resources.

7. Separate Retry Problems From Fresh Work

Shopify advises callers to regulate request rates, handle errors, and wait before retrying after throttling. Repeated requests without that pause can keep the integration from recovering cleanly.[3]

Group failed records by cause. A missing required field needs a data fix; a rate-limit response needs lower pressure or time to recover. Before retrying a timed-out create request, check whether the destination already created the record. Use a stable external ID or another supported duplicate-prevention method.

Replay a small corrected batch first. Confirm the records reached the right destination, then expand the retry. Compare the age of the oldest waiting record as well as run time: a faster run is not enough if old orders remain stuck.

How to Tell Whether the Fix Worked

Use the same record mix and similar load for a before-and-after comparison. Capture successful records per minute, error count, queue growth, and the time from the source change to the destination update. Reconcile record IDs and totals so speed does not hide missing or duplicate work.

Keep the successful setting, document why it helped, and watch the next busy period. If you need help, bring the run IDs, timestamps, slow-step evidence, and recent changes to a focused performance review.

References

Primary documentation reviewed September 30, 2026.

  1. Celigo: Configure connections to optimize throughput and governance.
  2. Oracle NetSuite: Concurrency governance and session management.
  3. Shopify: API limits.
  4. Celigo: Fine-tune integrator.io for optimal performance and data throughput.
  5. Celigo: Optimize multiple connections in your Integration App flows.
  6. Oracle NetSuite: Concurrency Monitor overview.

Get Your Orders and Inventory Moving on Time

Bring your slow flow and run history. We can help identify the cause, test a fix, and verify the records reach their destination.

Frequently Asked Questions

Practical answers about slow flows, API limits, and performance checks.

Why is my Celigo integration running slowly?

Possible causes include a busy connection queue, API limits, large exports, repeated lookups, and slow destination processing. Compare step timings, queue size, and errors to find where the delay begins.

Will increasing concurrency make my flow faster?

It may help when the endpoint has spare capacity and the flow has enough work to run in parallel. Raising concurrency when the API is already at its limit can increase errors. Check competing integrations first.

What page size should I use in Celigo?

There is no single best page size. Test against your record sizes, destination API, and concurrency settings. Compare successful records per minute and errors using the same record mix.

Why does my integration slow down during busy periods?

More records or competing jobs may use the same connection or destination capacity. Compare the queue and API usage during busy and quiet periods, then test moving bulk work to a different window.

Can NetSuite slow down a Celigo flow?

Yes. NetSuite account concurrency limits or slow record processing can affect imports. Compare the run with NetSuite Concurrency Monitor data and ask an administrator to trace slow records.

Should I use a delta export instead of a full export?

A delta export can reduce repeated work when only changed records are needed and the connector supports it. Verify the first load, change tracking, late updates, and recovery process before switching.

Should I retry every failed record right away?

First identify the cause. Fix invalid data before retrying and allow rate-limited requests time to recover. Check for an existing destination record before replaying a timed-out create request.

What should I collect before asking for performance help?

Collect flow and run IDs, timestamps, record counts, step timings, queue size, error codes, and recent changes. Include a comparable successful run and remove sensitive data from shared logs.