How the automation responds

Every automation has a response mode, chosen in its settings screen, and it decides what the call that triggers it gets back.

Mode	What the call receives	When to use it
Run in the background (default)	confirmation that the request was accepted, with the exec_uuid	long work, batches, scheduled runs
Wait for the result	the finished result, in the response body	a screen that is waiting, short reads and actions

In the background the automation runs on Fargate and has no duration limit: the result arrives through the webhook and shows up in the execution history. Waiting for the result it runs on Lambda and answers inside the request itself — the time is your automation's, and what the platform adds stays under 3 seconds.

Turning it on

In the automation's settings, under How the automation responds, pick Wait for the result.

The option only appears when the project supports the mode. The platform prepares that from the project's current image and makes a probe call before releasing it: if the image is too old, the screen says so instead of letting you find out on your first real call. If you have just published new code, run datallog push first.

The automation also has to be active

A disabled automation refuses the call with "Disabled Application, Please enable to run". New automations start disabled, and the number of active automations is capped by your plan.

The call budget

The front door cuts off at 29 seconds, so waiting for the result works with roughly 24 seconds. An automation that does not fit in that window is not an error:

• the response comes back 202 with the exec_uuid and a degraded field saying why;
• the run stays alive and finishes normally;
• the result arrives the usual way — webhook, history, or by checking the execution.

The caller has to handle both cases:

const r = await datallog.run('report', { month: '2026-10' });
const body = r && r.result !== undefined ? r.result : r;
if (body && body.exec_uuid) {
  // over budget: tell the user and fetch the result later
} else {
  // it came back ready
}

Through the REST API it is the same, with blocking in the body:

POST https://mwm.datallog.com/api/start-automation/<project>/<automation>
{ "seed": { "month": "2026-10" }, "blocking": true }

200 with the result when it fit; 202 with exec_uuid and degraded when it did not. The automation must be on Wait for the result — asking for blocking on one that runs in the background is refused, rather than holding the call open for nothing.

What does not change

The same code runs in both modes. The execution report is still produced, the history still records it, and billing is the same.