<div class="key-takeaways"><ul><li>งานรันประจำคืนทำข้อมูลตกหล่นถึง 300 แถวเงียบๆ จากปัญหา 429 Rate Limited</li><li>ข้อจำกัด UrlFetchApp ให้บริการ 20,000 ครั้ง/วัน สำหรับบัญชีทั่วไป และ 100,000 ครั้ง/วัน สำหรับ Workspace</li><li>ตั้งค่า muteHttpExceptions: true เพื่อให้ระบบสามารถดักจับสถานะโค้ดข้อผิดพลาดและทำการลองใหม่ได้</li><li>การใช้ Dead-Letter Queue บันทึกรายการที่ล้มเหลวลงในชีตช่วยป้องกันไม่ให้ข้อมูลสูญหายถาวร</li></ul></div><p>ปัญหาข้อมูลสูญหายอย่างเงียบๆ มักเกิดขึ้นได้เสมอเมื่อระบบรันงานอัตโนมัติในตอนกลางคืน เช่นเดียวกับเหตุการณ์ที่งานอัปเดตข้อมูลผลิตภัณฑ์ทำแถวข้อมูลหายไปเกือบ 300 แถวโดยไม่มีการแจ้งเตือนใดๆ สาเหตุหลักมาจาก API ฝั่งต้นทางส่งสัญญาณเตือน 429 Rate-Limited กลับมา ทำให้คำสั่ง UrlFetchApp.fetch เกิดข้อผิดพลาด ลูปการทำงานหยุดกลางคัน และเมื่อถึงรอบรันถัดไป ข้อมูลที่ตกหล่นก็หายไปเลยอย่างถาวร</p><p>ทุกการเชื่อมต่อผ่าน UrlFetchApp ย่อมต้องเผชิญกับปัญหานี้ในที่สุด ทางแก้จึงไม่ใช่แค่ฟังก์ชันฉลาดๆ เพียงตัวเดียว แต่ต้องอาศัยกลไก 4 เลเยอร์ที่จะช่วยป้องกันไม่ให้ความล้มเหลวชั่วคราวกลายเป็นการสูญหายของข้อมูล โดยโครงสร้างที่ใช้งานจริงประกอบด้วยแนวทางเหล่านี้</p><div class="stat-row"><div class="stat-item"><span class="stat-number">20k</span><span class="stat-label">โควต้าต่อวันสำหรับบัญชีทั่วไป</span></div><div class="stat-item"><span class="stat-number">100k</span><span class="stat-label">โควต้าต่อวันสำหรับ Workspace</span></div><div class="stat-item"><span class="stat-number">60s</span><span class="stat-label">เวลาหมดเขตต่อการเรียก 1 ครั้ง</span></div></div><p>ก่อนจะเริ่มลงมือเขียนโค้ด จำเป็นต้องเข้าใจข้อจำกัดต่างๆ ของระบบให้ดีเสียก่อน โดยแต่ละคำขอจะมีข้อจำกัดเวลาหมดอายุที่ 60 วินาที และจำกัดขนาดข้อมูลไว้ที่ 50 เมกะไบต์ต่อเที่ยว นอกจากนี้ยังมีข้อจำกัดเรื่องการเรียกพร้อมกัน (Concurrent calls) ต่อสคริปต์ที่อยู่ที่ประมาณ 10 ถึง 20 คำขอ ซึ่งหากทำแบบคู่ขนานโดยไม่ระมัดระวัง จะทำให้เกิดข้อผิดพลาด Service invoked too many times ทันที</p><div class="mb-20"><img class="img-bdrd-16" src="https://api.inewgen.co/uploads/urlfetchapp_apps_script_retry_dlq_ms9746zd_inline_1_8da2354bc7.jpg" alt="spreadsheet data error handling" loading="lazy" /><p class="color-gray-500 text-sm mt-10">ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง</p></div><p>รากฐานสำคัญเริ่มต้นที่บรรทัดคำสั่ง muteHttpExceptions: true เพราะหากปราศจากสิ่งนี้ สถานะ 429 จะโยนข้อผิดพลาดออกไปก่อนที่ระบบลองใหม่ (Retry) จะทันได้ตรวจสอบรหัสสถานะ โดยควรตั้งค่าให้ลองใหม่เฉพาะเมื่อเจอสถานะ 429 และ 5xx เท่านั้น เนื่องจากสถานะ 400 หรือ 401 จะไม่สามารถแก้ไขได้ด้วยตัวเอง จึงควรแสดงผลแจ้งเตือนทันที พร้อมทั้งใส่ Jitter (การหน่วงเวลาสุ่ม 0-500 มิลลิวินาที) เพื่อป้องกันไม่ให้ชุดสคริปต์จำนวนมากลองส่งคำขอซ้ำพร้อมกันจนไปถล่ม API</p><div class="ai-insight"><p>การทำความเข้าใจเรื่อง Rate Limit และ Quota เป็นหัวใจสำคัญของการพัฒนาสคริปต์บนคลาวด์อย่าง Google Apps Script เนื่องจากทรัพยากรมีจำกัด การออกแบบระบบที่มีความยืดหยุ่น (Resilient Architecture) จึงช่วยลดภาระของเซิร์ฟเวอร์ปลายทาง และป้องกันไม่ให้แอปพลิเคชันหยุดชะงักเมื่อมีปริมาณข้อมูลจำนวนมาก</p></div><p>สำหรับการเรียกใช้งานที่มีความอิสระต่อกันจำนวนมาก การใช้ UrlFetchApp.fetchAll จะช่วยรวบรวมคำขอส่งเป็นชุดเดียวแทนการวนลูปทีละรายการ ซึ่งช่วยประหยัดโควต้าได้อย่างมีประสิทธิภาพมากกว่า โดยควรจำกัดขนาดชุดข้อมูลอยู่ที่ประมาณ 10 ถึง 20 คำขอต่อรอบ เพื่อไม่ให้เกินขีดจำกัดการเชื่อมต่อพร้อมกัน</p><p>เลเยอร์สุดท้ายคือสิ่งที่จะช่วยกู้คืนข้อมูล 300 แถวที่เคยหายไป นั่นคือ Dead-Letter Queue เมื่อการลองใหม่ทั้งหมดล้มเหลว แทนที่จะปล่อยให้ข้อความหลุดลอยไป ให้เขียนบันทึกคำขอที่ล้มเหลวลงใน Google Sheets เพื่อให้สามารถนำกลับมาประมวลผลซ้ำ (Replay) ได้ตามต้องการ</p><p class="source-attribution">ที่มา: <img src="https://www.google.com/s2/favicons?domain=dev.to&sz=64" alt="Dev.to" class="source-logo" width="16" height="16" /> <a href="https://dev.to/hayrullahkar/urlfetchapp-quotas-retries-in-apps-script-backoff-rate-limits-a-dead-letter-queue-2d" target="_blank" rel="noopener noreferrer">Dev.to</a></p>

<div class="key-takeaways"><ul><li>A nightly product-enrichment job quietly dropped around 300 rows due to a 429 rate-limit error.</li><li>UrlFetchApp allows 20,000 calls per day for consumer accounts and 100,000 for Workspace.</li><li>Setting muteHttpExceptions: true allows retry logic to inspect status codes before failing.</li><li>Implementing a Dead-Letter Queue logs failed calls to a sheet to prevent permanent data loss.</li></ul></div><p>Silent data loss often sneaks into automated jobs running overnight, much like a product-enrichment script that quietly dropped nearly 300 rows without throwing an alert. An upstream API responded with a 429 rate-limited status, causing UrlFetchApp.fetch to fail, the loop to die midway, and the skipped rows to vanish permanently when the next execution started fresh.</p><p>Every UrlFetchApp integration eventually encounters this hurdle. The solution is not a single clever function, but four distinct layers designed to prevent transient failures from turning into permanent data loss. Here is the operational stack used to handle such workloads.</p><div class="stat-row"><div class="stat-item"><span class="stat-number">20k</span><span class="stat-label">Daily quota for consumer accounts</span></div><div class="stat-item"><span class="stat-number">100k</span><span class="stat-label">Daily quota for Workspace accounts</span></div><div class="stat-item"><span class="stat-number">60s</span><span class="stat-label">Timeout limit per individual call</span></div></div><p>Before implementing any retry patterns, it is vital to acknowledge system boundaries. Each call times out at 60 seconds and enforces a 50 megabyte payload cap in either direction. Furthermore, concurrent calls per script face an undocumented threshold hovering around 10 to 20 requests, meaning naive parallelism will quickly trigger 'Service invoked too many times' errors.</p><div class="mb-20"><img class="img-bdrd-16" src="https://api.inewgen.co/uploads/urlfetchapp_apps_script_retry_dlq_ms9746zd_inline_1_8da2354bc7.jpg" alt="spreadsheet data error handling" loading="lazy" /><p class="color-gray-500 text-sm mt-10">Stock photo for illustration only, not from the actual event</p></div><p>The core foundation begins with a single critical property: muteHttpExceptions: true. Without this configuration, a 429 status throws an exception immediately before retry logic can evaluate the response code. Retries should execute strictly on 429 and 5xx statuses, as error codes like 400 or 401 require manual intervention. Additionally, applying a random jitter between 0 to 500 milliseconds prevents a batch of scripts from synchronizing their retry attempts and hammering the target API simultaneously.</p><div class="ai-insight"><p>Understanding rate limits and API quotas is paramount when building scalable cloud scripts on platforms like Google Apps Script. Designing resilient architectures not only protects upstream servers from traffic spikes but also ensures long-term reliability for automated background operations.</p><p class="ai-insight-sub">By decoupling synchronous execution from error handling, developers can maintain robust data pipelines even when external dependencies experience temporary degradation.</p></div><p>When executing numerous independent requests, UrlFetchApp.fetchAll consolidates them into a single batch rather than running a slow sequential loop, optimizing quota consumption. Maintaining batch sizes around 10 to 20 requests helps respect upstream concurrency thresholds.</p><p>The final layer is what prevents data loss entirely: a Dead-Letter Queue. When all retry attempts are exhausted, writing the failed payload to a spreadsheet ensures that nothing disappears into the void and allows developers to replay the operations on their own schedule.</p><p class="source-attribution">Source: <img src="https://www.google.com/s2/favicons?domain=dev.to&sz=64" alt="Dev.to" class="source-logo" width="16" height="16" /> <a href="https://dev.to/hayrullahkar/urlfetchapp-quotas-retries-in-apps-script-backoff-rate-limits-a-dead-letter-queue-2d" target="_blank" rel="noopener noreferrer">Dev.to</a></p>

medium_urlfetchapp-apps-script-retry-dlq-ms9746zd.png

small_urlfetchapp-apps-script-retry-dlq-ms9746zd.png

thumbnail_urlfetchapp-apps-script-retry-dlq-ms9746zd.png

urlfetchapp-apps-script-retry-dlq-ms9746zd.png

เรียนรู้วิธีแก้ปัญหา API Rate Limit 429 และป้องกันข้อมูลสูญหายใน Google Apps Script ด้วย 4 เลเยอร์สำคัญ พร้อมเทคนิค Exponential Backoff และ Dead-Letter Queue

Learn how to handle API rate limits and prevent silent data loss in Google Apps Script using four resilience layers, exponential backoff, and a dead-letter queue.

Inewgen

Inewgen

#Google Apps Script

UrlFetchApp Quotas & Retries in Apps Script: Backoff, Rate Limits & a Dead-Letter Queue

Inewgen