Experiment record
Open-Meteo HTTP 429 only on Apps Script time-driven triggers
The same Google Apps Script collector returned HTTP 200 when run manually and HTTP 429 under a time-driven trigger. The evidence points more specifically to the Google-side outward path used by scheduled execution than to collector request logic. Aggregation with other Apps Script traffic through a shared Google egress identity remains a hypothesis, while a Cloudflare Worker relay restored the investigated workflow.
Summary
A Google Apps Script collector that requested data from Open-Meteo showed a repeatable difference between execution modes: the same function returned HTTP 200 when run manually but HTTP 429 when invoked by a time-driven trigger.
The investigation compared execution context, temporarily checked the outward network path, inspected the collector code, and then tested a Cloudflare Worker relay as a mitigation.
The retained evidence supports a more specific interpretation: the observed 429 was more likely associated with the Google-side outward network path used when the time-driven trigger accessed Open-Meteo than with a different request path inside the collector itself.
Google’s official documentation states that Apps Script UrlFetchApp uses Google’s network infrastructure and that requests originate from a set pool of Google IP ranges. This makes a shared-egress explanation plausible: the network identity used by scheduled execution may have influenced Open-Meteo’s usage-limit decision.
However, the experiment did not establish that Open-Meteo actually combined traffic from other Apps Script users or workloads into the same quota bucket. That specific aggregation mechanism remains a hypothesis.
The retained record indicates that scheduled collection recovered after requests were routed through a Cloudflare Worker relay. This is a path-changing workaround, not proof that Open-Meteo’s rate limits were removed or that the Worker received a permanently separate quota.
Background
A Google Apps Script collection function accessing Open-Meteo produced different outcomes depending on how it was invoked.
Manual execution succeeded with HTTP 200, while the same function returned HTTP 429 with a daily API request limit message when invoked by a time-driven trigger.
That raised several possibilities: a trigger-only extra request, a materially different application code path, or a difference in the outward network path used by the two execution modes.
The experiment was designed to separate those explanations without presenting an undocumented provider-side aggregation rule as fact.
Methods
Google Apps Script collector
The comparison used the same Google Apps Script collection function in both execution modes.
The function was run manually and through a time-driven trigger, then the HTTP outcomes and diagnostic execution context were compared.
The collection design retained timestamp-based deduplication and a bounded 72-hour history window.
Open-Meteo API
Manual execution returned HTTP 200 from Open-Meteo. Time-driven-trigger execution returned HTTP 429 with a daily API request limit message.
The retained record does not establish the exact rate-limit key or usage-aggregation unit used by Open-Meteo.
Comparison with official documentation
During the interpretation analysis on August 23, 2026, official Google and Open-Meteo documentation was compared with the retained observations.
Google’s official UrlFetchApp reference states that the URL Fetch service uses Google’s network infrastructure and that requests originate from a set pool of Google IP ranges. Apps Script requests therefore should not be assumed to have a unique egress identity dedicated to one script.
Open-Meteo’s Pricing documents usage limits for the Free API, including a daily limit, while its Terms state that IP-address information may be used for technical or misuse-prevention purposes and that applications and IP addresses may be blocked for misuse.
These official statements are consistent with a network-identity-related explanation, but they do not disclose which IP address, network identity, application identity, or combination Open-Meteo used to account for the requests in this incident.
Cloudflare Worker relay
As a mitigation, the provider request path was changed from direct Open-Meteo access to a Cloudflare Worker relay.
The retained record indicates that the investigated scheduled collection recovered after this change.
The complete Cloudflare Worker source code and a complete post-mitigation scheduled-run log were not retained.
Experiment Log
The retained source record does not preserve the exact timestamps of the individual operations, so the sequence below follows the recorded investigation path without inventing times.
Comparing manual and time-driven-trigger execution
Running the collection function manually returned HTTP 200 from Open-Meteo.
Invoking the same function through a time-driven trigger returned HTTP 429 with a daily API request limit message.
Because the same collection function behaved differently by execution mode, the result was not readily explained by the ordinary request URL or function logic alone.
Identifying execution context in diagnostic logs
Diagnostic logging used the trigger event object to distinguish manual runs as MANUAL and scheduled runs as TRIGGER.
This made it possible to compare outcomes while explicitly retaining the execution context of each run.
Temporarily checking the outward network path
A temporary external IP check showed different outward paths for the two execution modes.
Manual execution exposed IPv6, while time-driven-trigger execution exposed a different IPv4.
The exact addresses are withheld. The diagnostic endpoint was not Open-Meteo itself, so this observation does not prove that the diagnostic endpoint and Open-Meteo always saw the same egress identity.
Inspecting the collector for trigger-only extra requests
The collection code was inspected for additional Open-Meteo requests that occurred only under trigger execution.
No such trigger-only extra provider request was found. When HTTP 429 was returned, the retry loop stopped instead of continuing repeated calls to Open-Meteo.
For the inspected code, this did not support the explanation that extra trigger-only requests were causing the observed 429 behavior.
Routing through a Cloudflare Worker relay
The Open-Meteo request path was changed to go through a Cloudflare Worker relay.
The retained record indicates that the investigated time-driven-trigger collection recovered after this change.
Timestamp-based deduplication and the bounded 72-hour history window were retained.
Conclusion
The scheduled outward path was likely involved
The same collection function returned HTTP 200 manually and HTTP 429 under a time-driven trigger, while code inspection found no trigger-only extra Open-Meteo request.
A temporary check also observed different outward network paths between the two execution modes.
Taken together, this makes it more likely that the observed 429 was associated with the Google-side outward path used by scheduled execution than with a different ordinary request path inside the collector.
Google’s documentation that UrlFetchApp requests use Google’s network infrastructure and originate from a pool of Google IP ranges is consistent with this interpretation.
Possible aggregation through Google shared egress
A more specific mechanism is plausible: Open-Meteo may have treated the Google-side network identity or IP pool used by scheduled execution as a usage-accounting unit.
If so, Open-Meteo requests from other Apps Script workloads that appeared under the same source identity could have contributed to the same daily usage count, eventually producing the daily API request limit response seen by this trigger.
The experiment did not observe other users’ traffic or Open-Meteo’s internal quota bucket, so actual aggregation with other Apps Script traffic remains HYPOTHESIS rather than an observed fact.
Cloudflare Worker is a path-changing workaround
The retained recovery record after routing through a Cloudflare Worker shows that changing the outward path was operationally effective in the investigated case.
It does not show that Open-Meteo’s rate limits disappeared, nor does it establish how Open-Meteo accounts for traffic arriving through the Cloudflare path.
If Open-Meteo groups Cloudflare-originated traffic by a shared network identity and the aggregate request volume grows, a similar HTTP 429 could recur in the future. The Worker relay should therefore be treated as a workaround that changed the request path, not as evidence of permanently isolated quota accounting.
Evidence summary
The Evidence States for the information obtained in this Experiment are as follows.
| Recorded content | Evidence State |
|---|---|
| Interpretation that the 429 was more likely related to the Google-side outward path used by time-driven-trigger execution than to collector request logic | INFERRED |
| Possibility that Open-Meteo aggregated usage through a shared Google egress identity or IP pool, potentially including other Apps Script workloads | HYPOTHESIS |
| Retained record indicating that the investigated scheduled workflow recovered after routing through a Cloudflare Worker relay | OBSERVED |
| Possibility that a similar rate limit could recur if Cloudflare-originated aggregate usage later reaches the provider’s accounting threshold | HYPOTHESIS |
| Trigger-only extra Open-Meteo requests in the inspected application code as the cause of the observed 429 | DISPROVEN |
See Evidence State for the shared definitions.
Unresolved questions
The retained record does not establish:
- the exact rate-limit or usage-aggregation key Open-Meteo used when returning HTTP 429;
- whether other Google Apps Script workloads were actually counted together with this scheduled trigger’s traffic;
- whether the temporary IP-check endpoint and Open-Meteo always observed the same outward network identity;
- how Open-Meteo accounts for requests sent through the Cloudflare Worker path;
- whether a similar HTTP 429 will recur if aggregate Cloudflare-originated usage increases.
Resolving these questions would require provider-side specification/evidence or additional controlled observations of the relevant accounting behavior.
Operational implications
When the same application function produces different external API outcomes under manual and scheduled execution, troubleshooting should record execution mode, HTTP status, trigger context, and outward network path separately from the application request logic itself.
A successful relay should be treated as a path-changing mitigation rather than as removal of the provider’s rate limit unless the provider-side accounting rule has actually been verified.
If network-path diagnostics are needed, the investigation can preserve the relevant difference without publishing exact egress addresses, maintaining both diagnostic value and privacy.
Experiment data
The exact original execution timestamps and a complete post-mitigation scheduled-run log are not present in the records currently available.
The historical execution sequence therefore cannot be reconstructed precisely, and the post-mitigation success rate cannot be quantified from the surviving material.
The complete Cloudflare Worker source code used for the mitigation is also not retained as a public reproducible source-code artifact.
Reproduction resources
The main elements needed to understand or recreate the investigated setup are Google Apps Script, a time-driven trigger, the Open-Meteo API, and a Cloudflare Worker relay capable of changing the provider-facing request path.
Because the complete original collector and Worker code were not retained, this Experiment Log cannot reproduce the exact historical implementation by itself.
No dedicated purchasable hardware was used for this experiment.
Machine-readable experiment record
A machine-readable canonical record of this Experiment is published as JSON.