When Apps Script Time-Driven Triggers Quietly Run Out: Consolidating Gemini Automations into One Dispatcher

Guarantee "always exactly one trigger" with an install script

A nice property of the dispatcher approach is that trigger management itself becomes idempotent in code. Adding and removing triggers by hand tends to leave duplicates, wasting both slots and runtime budget. The function below deletes every existing dispatch trigger first, then recreates exactly one.

function installDispatcher() {
  // Sweep existing dispatch triggers (eradicate duplicate registrations)
  ScriptApp.getProjectTriggers()
    .filter(t => t.getHandlerFunction() === 'dispatch')
    .forEach(t => ScriptApp.deleteTrigger(t));
 
  // Create the single 5-minute trigger
  ScriptApp.newTrigger('dispatch')
    .timeBased()
    .everyMinutes(5)
    .create();
 
  console.log('dispatcher installed: 1 trigger / every 5 min');
}

When you want another job, you add one line to the JOBS array. The trigger count does not grow. That is what breaks the "the more features I add, the sooner triggers run dry" structure. If you want to tighten the permission design for deployment too, see least-privilege scope design for Apps Script and Gemini.

Cap Gemini calls per cycle

Even consolidated, if each job hammers the Gemini API without limit, you inflate the UrlFetch daily cap and your bill. I prefer to set a per-cycle cap on how many items a job processes, deferring the rest to the next cycle. Making steady, small progress on a fixed cadence is more stable than processing a large batch at once and hitting the six-minute cap partway through.

function runReviewReplyDraft() {
  const MAX_PER_RUN = 5; // Per-cycle Gemini call cap
  const pending = fetchPendingReviews(MAX_PER_RUN); // Fetch only what's unprocessed
  for (const r of pending) {
    const draft = callGemini(
      'gemini-flash-latest',
      'Write one polite reply draft to this app review:\n' + r.body
    );
    saveDraft(r.id, draft); // Save idempotently (same id overwrites)
  }
}
 
function callGemini(model, prompt) {
  const key = PropertiesService.getScriptProperties().getProperty('GEMINI_API_KEY');
  const url = 'https://generativelanguage.googleapis.com/v1beta/models/'
    + model + ':generateContent';
  const res = UrlFetchApp.fetch(url, {
    method: 'post',
    contentType: 'application/json',
    headers: { 'x-goog-api-key': key },
    payload: JSON.stringify({ contents: [{ parts: [{ text: prompt }] }] }),
    muteHttpExceptions: true,
  });
  const code = res.getResponseCode();
  if (code === 429 || code >= 500) {
    // Rate limits and transient faults: give up this cycle, defer to the next (no retry storm)
    throw new Error('retryable: ' + code);
  }
  const json = JSON.parse(res.getContentText());
  return json.candidates[0].content.parts[0].text;
}

With MAX_PER_RUN at 5, a job on a 15-minute interval processes up to 20 items an hour. For the review-reply drafts of my wallpaper apps (shipped on both App Store and Google Play), that cadence almost never let a backlog build up. Unless the workload is urgent, keeping each cycle light beats spinning faster — it is gentler on the trigger runtime budget and on the production work that ties directly to AdMob revenue. As a starting point I recommend keeping MAX_PER_RUN between 3 and 5 on a 5-minute dispatch. In my own setup that cut total trigger-runtime consumption by roughly 40%, and the noon exhaustion stopped happening. Raising the count is fine once you are stable at this number. The idempotency of the batch processing itself is something I dig into in idempotent Sheets batches built around the 6-minute cap.

Put the "it stopped" detector outside the script

The weakness of the dispatcher approach is that when triggers run dry and firing stops, the mechanism that would tell you it stopped dies with it. An in-script watchdog dies the moment the trigger does. So the heartbeat must be monitored from outside.

dispatch writes the current time to heartbeat on every cycle. Expose that as a small web endpoint that can be read from outside, and have an external uptime monitor poll it on a fixed interval. If the heartbeat has not updated within a set window, the monitor raises an alert.

function doGet() {
  const hb = Number(
    PropertiesService.getScriptProperties().getProperty('heartbeat') || 0
  );
  const ageMin = (Date.now() - hb) / 60000;
  // Treat anything older than 15 minutes since the last firing as abnormal
  const ok = ageMin < 15;
  return ContentService.createTextOutput(
    JSON.stringify({ ok: ok, ageMin: Math.round(ageMin) })
  ).setMimeType(ContentService.MimeType.JSON);
}

Deploy this as a web app and register it with an external monitor so you get notified the moment ok turns false; then a silent stall surfaces the same day. The first time it bit me, it was precisely because I had no such external monitor. Automation only becomes operations once it includes "confirming it is still running" — a lesson I learned only after it stopped.

Next step

First, log ScriptApp.getProjectTriggers().length in your own script to count how many triggers are running right now. If you have two or more time-driven triggers, they are worth folding into a single dispatcher. Move your existing functions into the JOBS array, run installDispatcher once, and your trigger count converges to one.