Make Incomplete Executions: Check Jobs and Messages Before Retrying

The short answer

Before retrying a Make incomplete execution, check what already happened outside Make. Find the destination customer or job, inspect the outbound message, and check whether an automatic retry is pending. Keep each external action marked confirmed present, confirmed absent or unknown. Choose a recovery scope only after those records and the customer's current wishes are reconciled.

An error can follow a successful external action whose response never reached the scenario. A run marked Resolved is therefore not the whole completion check. The result you need is the correct job record and an appropriate message state, with uncertainty still visible. This is an original proposed protocol for one failed enquiry-to-job workflow, not an account test.

First establish whether there is a saved run

Make's incomplete-execution documentation says storage is disabled by default and needs available capacity. Do not assume that enabling it now recovers a run that was never stored. If no saved execution exists, preserve the original enquiry reference and inspect destination records before deciding what separate recovery is possible.

For a stored run, record the scenario, original execution and incomplete-execution IDs, failed module and current status. Then inspect the retry queue. Make's automatic retry guide describes retries for RateLimitError, ConnectionError, ModuleTimeoutError and configured Retry handlers. A pending automatic attempt is work already in motion; do not create a competing manual recovery without understanding it.

Build the destination-state ledger

Follow the enquiry across the boundary between systems. Use its source ID and time to locate the destination customer, job and message. Search the destination's own logs or reference fields rather than relying only on a red module icon. Keep evidence references in an authorized workspace, with no customer data or private message links in a public example.

Use three states for every external action. Confirmed present means you have an identifiable destination record or provider event. Confirmed absent means your documented check supports absence within its stated scope. Unknown means the available evidence cannot settle the outcome. Unknown is a hold, not permission to replay. A provider's accepted message event also does not establish that the customer read it.

This is our editorial worksheet, not a native Make deduplication feature. It can live in a controlled spreadsheet or paper record. Do not put tokens, account credentials or actual customer content in it unless your authorized internal process requires that information.

Choose the narrowest justified recovery

Make's resolution guide says a retry resumes at the failed module using the stored configuration and requires an active scenario. Editing the live scenario alone does not repair that saved run; where correction is needed, use the incomplete execution's own resolution flow. These are prerequisites to inspect, not instructions to activate a scenario blindly. Deleting an incomplete execution is irreversible, so deletion is not this protocol's default response.

Scenario settings add an important qualification: Use updated variable values can affect whether current or original team and organization variables are used. Record the relevant choice and values the recovery depends on. Sequential processing controls ordering; it is not a universal duplicate guard or an exactly-once guarantee. Avoid blanket setting changes as a substitute for destination checks.

Rollback has a boundary

Make's rollback guide limits reversal to transaction-supporting actions, with commit settings affecting behavior. It specifically notes that sending through Gmail cannot be undone. Do not assume rollback withdraws a message or removes every external job. Record which actions support transactions and inspect the others separately.

For example, a fictional enquiry DEMO-ENQ-01 could already have job DEMO-JOB-14 while its acknowledgment step has failed. The correct recovery would preserve that job and resolve the message decision, not create another job to make the scenario appear complete. These invented IDs illustrate the check; they are not observed records or a claimed recovery result.

Close the recovery with reconciliation

After an authorized recovery attempt, compare the destination customer and job IDs with the original enquiry, inspect message-provider events, and confirm that no competing retry remains unexplained. Record the customer's latest response independently. If an external outcome is still unknown, keep the exception open with an owner and next review rather than treating a green status as proof.

Use the Make versus Zapier comparison for platform choice and the automation hub for broader workflow decisions. An estimate follow-up needs the same check that the next message is still appropriate. For a solo operator, one clear recovery owner and a small ledger can be enough; this guide does not recommend buying another system.