Intermittent 404 from Google Apps Script via HTTP — same request succeeds on retry

Questions
,
1

:bullseye: What is your goal?

Reliably call a Google Apps Script Web App from Make to validate, sort and number rows in Google Sheets before exporting PDFs and emailing them.

I need to resolve intermittent 404 errors without blindly rerunning the entire scenario, which could duplicate files and emails.

:thinking: What is the problem & what have you tried?

I use two HTTP “Make a request” modules that POST to the same Apps Script /exec URL.

Some requests succeed with HTTP 200 and valid JSON, while others return a Google HTML “Page not found” response. The failure affects both modules: sometimes several calls succeed before one fails, and sometimes the first call fails.

Rerunning a failed module with the same spreadsheet ID and expected count has succeeded.

Current settings:

  • Method: POST
  • Body: JSON string
  • Parse response: Yes
  • Allow redirects: Yes
  • Share cookies: No
  • Request compressed content: Yes
  • Timeout: 80 seconds

Increasing the timeout did not resolve the issue; failures occur well before 80 seconds. We previously tried the legacy HTTP module and a separate GET request to the redirect URL, but also encountered failures.

The Apps Script executions we inspected show “Completed,” without a visible unhandled exception. We have not yet correlated every failed Make request with its exact script execution.

The script returns JSON through ContentService.createTextOutput(). Google documents that this redirects to a one-time script.googleusercontent.com URL. Could redirect handling be involved? This is a hypothesis, not a confirmed cause.

Has anyone encountered this and found a reliable solution or alternative approach? I have also opened a Make support ticket.

:clipboard: Error messages or input/output bundles

Failure shown in Make:
Data couldn’t be processed
Not Found
Code: DataError
Origin: HTTP

The response is a Google HTML page titled “Page not found”, containing:
“Sorry, unable to open the file at present.”
“Please check the address and try again.”

Example POST body (file ID redacted):

{
  "fileId": "<test-spreadsheet-id>",
  "sheetName": "Sheet1",
  "expectedCount": 2
}

Successful response when rerunning the same request:

{
  "statusCode": 200,
  "data": {
    "ok": true,
    "fileId": "<same-test-spreadsheet-id>",
    "sheetName": "Sheet1",
    "studentCount": 2,
    "empty": false
  }
}
4

Hello,

Once the error happens again, copy its request and try once again in a few minutes.
You can do it using the Run replay function →

Or use Run this module option →

Zrzut ekranu 2026-09-30 o 03.04.12
Zrzut ekranu 2026-09-30 o 03.04.12362×386 22.6 KB

So, if using the same data you will get:

  1. Success - that means the error is on Google’s side. You should use proper error handling, for example using a break module.
  1. Fail - you should validate your request. Maybe there are some typos or an invalid request?

Have a nice day.

5

I’ve hit similar flaky 404s calling Apps Script web apps from Make. Same payload succeeds on a replay a minute later. Besides the Break/retry path already suggested, two things that reduced my random failures: keep the web app deployed as Execute as Me + Anyone and always call the current deployment /exec URL (not /dev), and treat Google’s one-time script.googleusercontent.com redirect carefully. If the POST body isn’t preserved the same way through redirects, you can get HTML “Page not found” even when the script logged Completed. I also add a filter after the HTTP module that only continues when the body is real JSON, so a 404 HTML page never fans out into PDF/email steps.

7

One thing I’d add, since the real worry is duplicates on a retry: make the Apps Script side idempotent, then a Break with automatic retries becomes harmless. Send a run key with each request (the scenario’s execution ID plus the spreadsheet ID works), and in doPost take a script lock with LockService and check PropertiesService for that key before doing anything. If the key is already there, return the stored result instead of sorting and numbering again, otherwise do the work and store the result under the key.

That way a retry after one of these random 404s can never number rows twice, and together with the “only continue on real JSON” filter carus mentioned, the PDF and email steps only run once per batch.

8

The intermittent HTML 404 from the Apps Script /exec URL is Google’s behavior, not your scenario — the endpoint sometimes serves a redirect or ‘not found’ page on cold starts, then the identical request succeeds. Raising the timeout won’t help. Instead, add an error-handler route on the HTTP module: if the status isn’t 200 or the body isn’t valid JSON, Sleep with exponential backoff and retry the module using Make’s Break directive. Make the script idempotent by sending a unique run ID and checking it against asmall ‘processed runs’ store before acting, so retries never double-process rows. Scope the retry to the HTTP module only.

9

I’d be careful about treating every 404 as retryable.

If the same request can genuinely return both 404 and 200, I’d probably log the response body and headers as well as the status code before deciding on the retry path. A real “not found” response and a transient platform/endpoint problem can otherwise look identical to the scenario.

I’d also keep the retry limited to this HTTP step rather than retrying the whole scenario, especially if anything before it has side effects.