My polling flow picks up the same records each run or misses new ones
A polling flow without a cursor (last-seen id or timestamp) is unreliable. Either it duplicates records, or it misses them during a race condition. Cursor-keeping is a 5-minute fix with big impact.
Try this first
- 1Store a cursor record per flow: a Data Store entry, a sheet cell, or a DB row with last-processed timestamp or id.
- 2Read the cursor at the start of each run. Ask the source API for records since that cursor (look for 'updated_after', 'since', 'cursor', 'page_token').
- 3Process records in order of modification, not random. Otherwise the cursor desynchronises from reality.
- 4Write the new cursor only after successful processing. If the run fails midway, the next run resumes from the old cursor cleanly.
- 5Test the race condition: change 100 records in fast succession, run the flow, confirm no record is duplicated or missed.
When to bring us in
Got polling flows with duplicate-or-miss issues, a cursor implementation is usually the whole fix. We can help.
See also
- n8n: self-host or cloud?Self-hosted is cheaper at volume and keeps data local. Cloud removes ops burden.
- Zapier or Make: which fits better?Zapier is straight-line; Make handles complex flows with routers and iterators for less money.
- Power Automate Cloud or Desktop: which to use?Cloud for SaaS integrations and triggers. Desktop for RPA against legacy Windows apps without APIs.
None of the above fits?
Describe your situation below. We pass your input plus the steps you already saw to our AI and return tailored next-step advice. If it's too risky to DIY, we'll say so.
Or skip the DIY entirely
Our Managed IT clients do not look these things up. One point of contact, a fixed monthly price, resolved within working hours.