Kuota Google Apps Script 2026: Panduan Analis FP&A

Tiga skenario berikut adalah yang paling umum di tim FP&A. Masing-masing sudah dilengkapi dengan kalimat yang bisa langsung Anda sampaikan ke tim teknis, tanpa perlu memahami detail teknisnya.

Situasi 1: Laporan terjadwal tidak masuk ke inbox, tanpa notifikasi apapun.

Kemungkinan besar: script yang mengirim laporan berhenti karena melampaui batas eksekusi 6 menit. Tidak ada pesan error yang dikirimkan ke penerima maupun ke Anda - laporan itu hanya tidak ada.

Sampaikan ke developer: "Tolong cek apakah script laporan pagi kita kena batas eksekusi 6 menit. Kalau iya, minta dia optimalkan pembacaan data dengan getValues() bukan getValue() di dalam loop, atau pertimbangkan untuk memecah script menjadi beberapa bagian yang lebih kecil."

Situasi 2: Formula di sel tiba-tiba menampilkan Error setelah dataset bertambah besar.

Kemungkinan besar: formula tersebut adalah custom function dengan timeout 30 detik, bukan formula bawaan Sheets. Gunakan checklist di atas untuk memastikan. Ketika data bertambah, kalkulasinya melampaui batas waktu dan sel hanya menampilkan Error tanpa penjelasan yang memadai.

Sampaikan ke developer: "Formula kustom ini sepertinya kena timeout 30 detik. Tolong konversikan logikanya menjadi script biasa yang dijalankan melalui tombol atau jadwal, dan tulis hasilnya ke sel sebagai nilai statis."

Situasi 3: Beberapa otomasi di model berhenti bergantian, terutama di sore hari.

Kemungkinan besar: akun consumer Gmail sudah menghabiskan jatah 90 menit runtime harian. Trigger berikutnya tidak bisa berjalan sampai kuota direset tengah malam waktu Pasifik.

Sampaikan ke manager atau tim IT: "Kita perlu upgrade ke Google Workspace, atau konsolidasi beberapa script yang ada menjadi lebih sedikit proses. Kuota runtime harian kita sudah tidak cukup untuk volume otomasi yang sekarang."

Tabel Kuota Lengkap

Ada dua kategori limit: limit per-eksekusi yang menghentikan satu script secara individual, dan kuota harian yang terakumulasi di seluruh alur kerja.

Limit per-eksekusi (script langsung berhenti tanpa pemulihan):

Kuota harian (direset tengah malam waktu Pasifik):

Sumber: Halaman resmi Google Apps Script Quotas (developers.google.com/apps-script/guides/services/quotas), diverifikasi Juli 2026.

Perbedaan terbesar antara consumer dan Workspace ada di runtime harian dan volume email. Batas eksekusi 6 menit berlaku sama untuk semua akun - tidak ada cara untuk memperpanjangnya, terlepas dari paket yang digunakan.

Tembok 6 Menit: Mengapa Otomasi Bisa Berhenti Tiba-tiba

Batas ini tidak terasa seperti masalah sampai ia benar-benar menghentikan pekerjaan Anda di momen paling krusial.

Bayangkan skenario yang umum di tim FP&A: sebuah script diatur untuk berjalan setiap malam, menarik data aktual dari tab Laba Rugi, menghitung variansi terhadap anggaran di 36 bulan, menandai item yang melebihi threshold, lalu mengirimkan ringkasan per email ke CFO. Script ini berjalan baik selama berbulan-bulan sampai model berkembang, tab bertambah, dan tiba-tiba eksekusi malam itu berhenti tepat di menit ke-6 sebelum langkah pengiriman email. CFO tidak menerima laporan. Tim tidak tahu ada masalah sampai pagi hari.

Penyebab paling umum adalah cara script membaca data dari Sheets: setiap kali script meminta nilai satu sel, ia melakukan satu "perjalanan" ke Sheets API. Script yang membaca 500 baris data satu sel per waktu melakukan ratusan hingga ribuan perjalanan tersebut, dan setiap perjalanan membutuhkan waktu. Teknik yang benar adalah membaca seluruh rentang sekaligus dalam satu perintah, memproses data di memori, lalu menulis semua hasilnya sekaligus. Pendekatan ini bisa memangkas waktu eksekusi hingga sekitar 95% untuk dataset yang besar.

Menurut dokumentasi resmi Google Apps Script Quotas (developers.google.com/apps-script/guides/services/quotas, diakses Juli 2026): "Jika sebuah script melampaui kuota atau batasan, script tersebut dihentikan dan pesan error ditampilkan." Error yang muncul adalah Exceeded maximum execution time. Data yang sudah berhasil ditulis sebelum batas tercapai akan tersimpan - proses yang belum selesai hilang tanpa notifikasi kepada siapapun.

Untuk diteruskan ke developer Anda:

Kalau Anda bukan yang menulis scriptnya, forward bagian ini ke developer dengan catatan: "Tolong cek apakah script kita melakukan pembacaan data seperti yang lambat di bawah ini."

// Lambat: 1.000 panggilan API untuk 500 baris - mudah memakan 3+ menit
for (var row = 2; row <= 501; row++) {
  var actual = sheet.getRange(row, 3).getValue();  // 1 perjalanan ke API
  var budget = sheet.getRange(row, 4).getValue();  // 1 perjalanan lagi
}

// Cepat: 2 panggilan API untuk data yang sama - selesai dalam hitungan detik
var data = sheet.getRange('C2:D501').getValues(); // baca semua sekaligus
// proses di memori, tulis hasil sekaligus

Kalau Anda bukan yang menulis script ini, yang perlu disampaikan ke developer cukup satu kalimat: "Gunakan getValues() untuk membaca rentang data, bukan getValue() di dalam loop." Perubahan itu biasanya sudah cukup untuk menyelesaikan masalah timeout pada dataset berukuran sedang.

Limit Custom Function: 30 Detik, Bukan 6 Menit

Custom function adalah formula buatan developer yang bisa dipanggil dari sel Sheets seperti =HITUNG_WACC(B3:B10) atau =MARGIN_BERSIH(C5:C50). Karena tampilannya persis seperti formula bawaan, banyak analis mengira perilakunya sama dengan SUMIFS atau VLOOKUP.

Bedanya: custom function punya timeout 30 detik, bukan 6 menit. Ia juga berjalan di lingkungan yang lebih terbatas: tidak bisa menulis ke sel lain, tidak bisa mengirim email, dan tidak bisa mengakses layanan yang memerlukan otorisasi pengguna.

Selama custom function hanya melakukan kalkulasi matematika pada data yang dimasukkan langsung ke dalamnya, 30 detik lebih dari cukup. Masalah muncul ketika custom function dibangun untuk melakukan lebih dari itu: menarik data dari beberapa tab berbeda, melakukan lookup terhadap ledger ribuan baris, atau menerapkan logika multi-langkah sebelum mengembalikan satu angka. Semua itu bisa melewati 30 detik, dan sel hanya menampilkan Error tanpa penjelasan yang memadai - persis seperti yang sering dialami dengan formula WACC atau margin yang datanya terus bertambah dari waktu ke waktu.

Kalau custom function di model Anda sering bermasalah setelah dataset bertambah besar, solusinya bersifat arsitektural: fungsi tersebut lebih tepat dikonversi menjadi script biasa yang dijalankan melalui tombol atau jadwal otomatis. Hasilnya kemudian ditulis ke sel sebagai nilai statis. Pendekatan ini memberikan anggaran waktu penuh 6 menit dan akses ke semua fitur Sheets.

Runtime Harian: Di Sinilah Workspace Membuktikan Nilainya

90 menit per hari terdengar banyak, sampai Anda memperhitungkan berapa banyak trigger yang berjalan secara paralel.

Script yang me-refresh Laba Rugi bergulir setiap jam, misalnya, mungkin membutuhkan 2-3 menit per eksekusi. Dengan frekuensi per jam, Anda sudah menghabiskan 48-72 menit dari jatah 90 menit - hampir tidak ada ruang untuk otomasi lain yang mungkin dibutuhkan tim di hari yang sama.

Akun Workspace mendapatkan 6 jam (360 menit) runtime harian, hampir empat kali lipat dari consumer. Untuk tim yang menjalankan beberapa otomasi sekaligus - refresh aktual harian, distribusi laporan mingguan, monitoring anggaran terjadwal - selisih ini bisa menentukan apakah seluruh sistem berjalan lancar atau terus kehabisan kuota di pertengahan hari.

Kuota trigger (20 per script) berlaku sama untuk kedua tier. Kalau Anda memiliki banyak proses independen yang masing-masing membutuhkan jadwal sendiri, batas 20 ini bisa tercapai lebih cepat dari yang diperkirakan.

Kapan Batas Ini Muncul di Pekerjaan Sehari-hari

Tidak semua analis FP&A menulis Apps Script. Tapi batas-batas ini tetap relevan karena berjalan di balik layar add-on, otomasi terjadwal, dan alat yang mungkin sudah digunakan tim Anda tanpa disadari.

Beberapa situasi yang paling sering memunculkan error terkait kuota:

Refresh model besar yang tiba-tiba gagal. Model dengan lebih dari 10 tab dan ribuan formula lintas-tab bisa membutuhkan waktu lama untuk diproses, terutama jika ada script yang memperbarui nilai-nilai tersebut secara otomatis. Kalau refresh yang tadinya memakan 3 menit tiba-tiba butuh 7 menit karena data bertambah, script langsung dihentikan di tengah jalan.

Formula kustom yang menampilkan Error tanpa sebab jelas. Kalau developer Anda membangun formula kustom yang mengambil data dari banyak sumber sekaligus, formula itu mungkin bekerja baik saat dataset kecil dan mulai timeout ketika data bertumbuh melewati ratusan baris.

Laporan terjadwal yang tidak terkirim. Script yang mengirim email ringkasan setiap pagi mungkin berjalan lancar selama berbulan-bulan, lalu tiba-tiba berhenti karena model yang diproses sudah terlalu besar untuk diselesaikan dalam 6 menit. Tidak ada notifikasi - penerima laporan hanya tidak menerima email tanpa penjelasan apapun.

Trigger yang tidak berjalan sesuai harapan. Apps Script tidak menjamin presisi waktu. Trigger yang diatur "setiap jam" bisa aktif kapan saja dalam jendela satu jam tersebut, bukan tepat di menit pertama. Untuk laporan yang harus sampai di inbox CFO sebelum rapat pukul 07.00, trigger yang diatur pukul 05.00 dengan buffer yang cukup jauh lebih aman daripada trigger pukul 06.45 yang berharap semuanya berjalan sempurna.

Batas Praktis Apps Script untuk Model Keuangan

Berdasarkan struktur kuota yang ada, Apps Script menangani skenario berikut dengan baik:

• Model hingga sekitar 2.000 baris di 8-10 tab, dengan script yang menggunakan pembacaan batch
• Siklus refresh per jam atau lebih jarang
• Daftar distribusi email di bawah 1.500 penerima (Workspace) atau 100 penerima (consumer)
• Hingga 20 proses monitoring atau refresh berbeda per model

Apps Script mulai bermasalah ketika: ledger transaksi lebih dari 5.000 baris dengan logika alokasi yang kompleks, model dengan lebih dari 15 tab yang perlu diperbarui setiap 10 menit, atau kalkulasi yang membutuhkan banyak panggilan ke API eksternal yang masing-masing memakan beberapa detik.

Untuk tim FP&A yang tidak ingin berurusan dengan batas-batas ini secara langsung - terutama tim tanpa developer internal yang bisa mengoptimalkan script - pendekatan alternatif adalah menggunakan alat yang menjalankan operasi Sheets di sisi server, di luar konteks eksekusi Apps Script sepenuhnya. ModelMonkey bekerja dengan cara ini: kalkulasi dan pemrosesan data dilakukan di luar Apps Script, sehingga batas 6 menit dan timeout 30 detik tidak berlaku. Ini relevan terutama untuk tim yang menjalankan model besar secara rutin dan mengalami error timeout yang berulang tanpa solusi teknis yang mudah.