How to Retry a Failed Screenshot API Task in Make
Retry a failed screenshot API task in Make by inspecting the incomplete execution, fixing configuration errors, and safely retrying temporary failures.
To retry a failed screenshot API task in Make, open the scenario’s Incomplete executions, inspect the failed module, correct any configuration problem, then retry the execution if the error is temporary. Make resumes at the failed module using the settings saved when the failure happened, so a retry does not automatically pick up changed settings. Make’s incomplete execution guide explains the process.
Retry a failed execution in the Make interface
- Open the scenario and select Incomplete executions.
- Find the failed execution and open its details. Inspect the error or warning on the screenshot API module. Check the execution history and module settings to identify the cause.
- Classify the error. A temporary connection problem or a rate limit that has cleared may be suitable for retry. A malformed request, invalid credential, or other data or configuration problem usually needs correction first.
- If the saved request is wrong, resolve the incomplete execution or update its saved blueprint before retrying. Correct the endpoint, credential, mapped fields, or module settings as appropriate.
- Confirm the scenario is active. Select the incomplete execution and choose Retry selected.
- Watch its status. Make describes it moving from Scheduled in to In Progress, then Resolved after a successful retry. If it remains unresolved, inspect the new module error rather than repeatedly retrying without a change.
A retry is best suited to temporary errors such as connection failures and rate limits. It runs with the configuration from when the error occurred. If you changed the scenario afterward, verify whether the incomplete execution uses that updated configuration before relying on it.
Choose between retrying and fixing the request
| What you see | Likely next step |
|---|---|
| Connection error or temporary network interruption | Check that connectivity has recovered, then retry the incomplete execution. |
| Rate limit response | Wait for the limit to clear, check the screenshot provider’s rate-limit guidance, then retry. |
| Invalid URL, missing parameter, or malformed request | Correct the mapped input or request configuration before retrying. |
| Authentication or authorization failure | Repair the credential or permissions, then make sure the retry uses the corrected settings. |
| Runtime or data error | Inspect the failed module’s inputs and output. Make notes that these errors often require manual resolution. |
| Screenshot task may have completed but Make timed out | Check the scenario or provider task status before issuing another screenshot request. |
Repeating a screenshot request may create another provider request, billable capture, or duplicate output. Whether that happens depends on the screenshot API. Before setting up automatic retries, check its documentation for idempotency, retry guidance, rate limits, and task-status lookup. The Make retry itself does not establish that repeating the provider request is safe.
Retry incomplete executions with the Make API
For programmatic recovery, Make provides endpoints to list and retry incomplete executions. The API documentation requires the dlqs:write scope for retry endpoints. Use your Make API base URL and authorization setup as required by your account; the examples below show the endpoint paths and request shapes documented by Make.
List a scenario’s incomplete executions
curl --get "$MAKE_API_BASE/dlqs" \
--data-urlencode "scenarioId=$SCENARIO_ID" \
-H "Authorization: Token $MAKE_API_TOKEN"Retry one incomplete execution
curl -X POST "$MAKE_API_BASE/dlqs/$DLQ_ID/retry" \
-H "Authorization: Token $MAKE_API_TOKEN"Retry multiple executions
curl -X POST "$MAKE_API_BASE/dlqs/retry" \
-H "Authorization: Token $MAKE_API_TOKEN" \
-H "Content-Type: application/json" \
-d '{"executionIds":["EXECUTION_ID_1","EXECUTION_ID_2"]}'Make also documents bulk retry options for selecting executions and optional exclusions. Incomplete executions are queued, so a large retry batch may not begin immediately. Check the response and execution status instead of assuming that a successful API call means the screenshot has already been captured. If the failed execution needs a changed blueprint, update it with PATCH /dlqs/{dlqId} before retrying. See Make’s incomplete executions API reference for the exact request fields and response schema.
Handle Make API timeouts and webhook retries
If Make started the scenario through its API, a responsive-call timeout does not necessarily mean that the scenario stopped. Make documents that the API call can time out after 40 seconds while scenario execution continues, and supports a callback URL for completion information. Check execution status before starting another screenshot task, or a retry may duplicate work. See Make’s scenarios API documentation.
For webhook-triggered scenarios, distinguish a failure in the screenshot API module from the webhook caller’s own behavior. Make documents that an error stops an immediately running webhook scenario at once, while a scheduled scenario stops after three unsuccessful attempts. Webhook rate limiting can also return HTTP 429 to callers. These behaviors affect how events reach the scenario; they do not tell you whether the screenshot provider safely accepts a repeated capture. See Make’s webhook documentation.
Common errors and fixes
| Error or symptom | Cause to check | Fix |
|---|---|---|
| Retry fails with the same error | The incomplete execution reused its original settings, or the underlying issue remains. | Inspect the failed module again. Correct the saved request or blueprint, then retry. |
| Authentication error persists | The stored credential is invalid, expired, or lacks permission; the incomplete execution may still hold old settings. | Update the credential and ensure the incomplete execution uses the corrected configuration. |
| HTTP 429 or rate-limit error | The screenshot API or Make webhook caller is rate limited. | Wait for the relevant limit to clear and consult that service’s rate-limit rules. Avoid an immediate retry loop. |
| Make API retry request is rejected | The token may lack the required dlqs:write scope, or the request path or execution ID may be wrong. |
Check the token scope and confirm the endpoint and ID against Make’s API reference. |
| Bulk retry appears delayed | Make queues incomplete executions, and large batches may not start immediately. | Check execution status and allow the queue to process before submitting the same batch again. |
| Two screenshots or outputs appear | The original task may have completed despite a timeout, then a second request was submitted. | Check Make’s execution and the screenshot provider’s task status before resubmitting. Use provider-supported idempotency if available. |
| Webhook event did not complete | The scenario stopped on an error or webhook delivery was rate limited. | Inspect the scenario execution separately from the caller’s delivery result, then recover the incomplete execution as appropriate. |
Reliability, performance, and cost considerations
- Retry only after diagnosis. A bounded retry after a transient connection failure or cleared rate limit can recover without changing the request. Repeating a permanent input error just produces another failure.
- Check for work still in progress. A Make API timeout may leave the scenario running. Confirm execution or task status before creating a second request.
- Use the provider’s retry contract. Provider-specific billing, idempotency, concurrency limits, and task lookup are not determined by Make’s incomplete execution behavior.
- Expect queue delay for bulk recovery. Submitting a batch does not guarantee that every execution starts immediately. Monitor the execution states.
- Keep recovery observable. Record the original execution identifier, failure reason, retry time, and final status in your own operational process so repeated failures can be diagnosed.
Or skip the browser setup
If the failure is really about operating a screenshot service rather than recovering a Make execution, ScreenshotNeo is a website screenshot API and MCP server. Make an HTTP GET request with a URL to get an image or PDF. The one-call example below saves a WebP response; see the ScreenshotNeo API documentation for request options and response details.
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webpScreenshotNeo accepts cookie and consent banners like a visitor, then removes more than 60 known consent platforms along with newsletter popups and chat widgets before capture; each step can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits cost nothing, and the response identifies the page verdict and billing status in headers. Its MCP server provides take_screenshot, get_page_info, and capture_pdf tools for Claude, Cursor, and other MCP clients. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000 screenshots.
Sign up for 1,000 free screenshots a month, with no card.
FAQ
Does retrying rerun the entire Make scenario?
Make’s incomplete execution retry resumes from the failed module, using the configuration saved when the error occurred.
Will a retry use settings I changed after the failure?
Not automatically. Make says retries use the same configuration as when the error happened. Update or resolve the saved incomplete execution as needed before retrying.
Can I retry every failed screenshot request automatically?
Only after checking both Make’s error and the screenshot provider’s retry, billing, and idempotency rules. Some failures require a configuration fix, and a repeated request may duplicate work.
What does a successful retry mean?
Make marks the incomplete execution resolved when the retry succeeds. Confirm that the expected screenshot output was also produced and delivered to the next module.
