Make Completion Heartbeat Guide

A scheduled automation needs to finish useful work, not just start. An outside completion heartbeat adds a deadline for the signal your scenario sends after its own success checks. If that signal is missing, you have something to investigate. Keep Make's existing monitoring and error handling alongside it.

This guide is documentation-based. We have not run this Make setup or verified alert receipt for it. The example below is illustrative and untested, not an importable blueprint or a native Job Heartbeat integration.

1. Choose a recurring obligation

Start with one noncritical scenario that should complete at a predictable interval. Check the active Make schedule, timezone, expected duration and normal delays. A scenario that runs only when an occasional event arrives can legitimately remain quiet; a missing heartbeat is useful only when there was a real expectation of completion.

Write down the result that counts as success before placing the heartbeat. For example: the report for this reporting period exists at the expected destination and its required fields pass your checks. An HTTP response or green run alone does not establish that result.

2. Create the check and confirm your email

Use Job Heartbeat's existing browser setup:
https://beat.austinoaksapi.com/

Open the signup confirmation link, then press “Confirm my email.” Both steps are required to enable alert email. Receiving that confirmation email does not establish that a later alert will arrive.

Choose a cadence that fits the expected completion interval. The browser assigns grace automatically. For example, its hourly choice has five minutes of grace, giving a 65-minute missing-heartbeat threshold. Monitoring starts when the check is created, so account for the first run too. Review the timing shown during setup; this is an elapsed-time expectation, not a promise to mirror every Make calendar schedule.

Copy the check's private heartbeat URL. The workflow needs that URL, not your account API key. Keep both private, including in screenshots, shared scenario exports and logs.

3. Put the ping after the final success check

Illustrative, untested example: an hourly report scenario gets one reporting-period input, prepares one report, writes it to the intended destination, reads back the required result and validates it. Only the passing result reaches the completion HTTP request. A missing, stale or invalid report does not.

Intended order: scheduled work, required destination result, success validation, one completion request. For transactional destinations, wait for durable commit before the ping; a readback before commit is not durable success.

For this simple example, keep required work on one linear path and ensure exactly one completion bundle reaches the request. Do not place the request before the write, in general cleanup, or on an error-handling route. Do not send one heartbeat per row and call that proof the whole batch finished: an early row can succeed while a later row fails.

If your scenario produces several bundles or uses branches, stop and define the whole-run completion condition before adapting this example.

4. Check the Make-specific traps

Routers: Make processes router routes sequentially, but route order alone is not proof that every required result succeeded. A separate heartbeat route, even last, can still be reached when another route was filtered out or handled a failure. A fallback route is for data that did not match other routes, not a universal “everything succeeded” route. Keep the simple example linear; multi-route completion needs a separately reviewed design.

Errors: Skip removes a failed bundle and lets other bundles continue; Make can still mark the run successful. Resume supplies substitute data and continues. Neither proves the original required action succeeded. Do not allow missing work or placeholder data through the completion gate. Retries and incomplete executions also need resolution before you claim full completion.

No output: a polling trigger may find nothing and emit no bundles. A filter also stops bundles that fail its condition. The absence of a bundle at the end does not tell you whether there was legitimately nothing to do or the intended work was lost. Define valid “nothing to do” explicitly and make it observable before using it as success.

Aggregation: an aggregator can emit an empty result by default; “Stop processing after an empty aggregation” changes that behavior. Aggregation is scoped to its source operation, and grouping can produce multiple output bundles. An aggregator alone is not a whole-run success test. Check the expected item set, missing items and required results, and verify the number of completion requests. Do not silently discard failed items and validate only the survivors.

5. Configure the completion request

After the passing completion gate, add HTTP > Make a request. These field names follow Make's current HTTP Version 4 documentation; legacy versions may differ.

Authentication type: No authentication
URL: the private heartbeat URL copied from your own check
Method: GET
Request body, extra query parameters and authentication headers: none
Parse response: Yes
Pagination: leave unconfigured
Return error if HTTP request fails: Yes
Allow redirects: No; investigate an unexpected redirect instead of forwarding the private URL

Do not paste a real heartbeat URL into a public example or visit it merely to inspect it: requesting it sends a heartbeat.

Inspect the response status and body during your own pilot and verify the check recorded the completion. The HTTP error setting covers 4xx and 5xx responses; an unexpected 3xx must also remain unresolved, not count as an accepted heartbeat. Job Heartbeat documents that excess pings above its 10-per-minute limit can return HTTP 200 with “dropped”: true; that signal was ignored. A green HTTP module is therefore insufficient evidence on its own. This guide does not invent an exact normal response payload or provide a tested response-validation formula. Treat dropped, malformed or ambiguous responses as unresolved. Do not add blind retries that could disguise a late or incomplete run.

6. Verify the alert you will rely on

When you choose to test, use only your noncritical pilot. Confirm a real successful completion first. Pause that pilot long enough to pass its expected deadline, then check that the alert actually reaches the intended mailbox. Resume the scenario and verify a later scheduled completion. Record what happened, including the actual email receipt; provider acceptance and an “up” check do not prove delivery to your inbox.

No such test has been performed for this guide. Keep existing monitoring while you evaluate the pattern.

Job Heartbeat observes the signal your scenario chooses to send. It does not independently validate report quality, destination correctness, every branch, or exactly-once external effects. The existing free plan is available for a noncritical comparison; review the current plans and setup details before starting:
https://beat.austinoaksapi.com/