Make Event subscriptions: receive alerts when an automation fails

Make Event subscriptions allows you to receive notifications about events on the platform, including those affecting organizations and scenarios. For an SME using AI automations, it is a way to bring an operational signal to a prearranged endpoint. It is not a new autonomous AI capability and does not guarantee that someone will solve the problem on their own.

The function appears in Make updates of the 8 October 2026 and is in beta. Notifications come via POST requests to a public HTTPS endpoint, without building a dedicated polling scenario. Teams has three subscriptions per organization, while Enterprise provides unlimited. Updates Make and official introduction.

The concrete benefit depends on the recipient: he must verify the request, register it and direct it to the correct manager. An alert left in a channel that no one follows does not improve the continuity of the process. Before activating the notifications you need to then decide what to do when they arrive.

Why can a failed automation remain invisible?

An automatic process can stop updating the CRM, prepare documents, or submit requests while staff continue to work. If the error remains only in the technical panel, those who wait for the result may notice it late. The difficulty is not always to detect the failure: it is to get the signal to the person who can intervene.

Platform events provide a starting point for building this link. The notification describes an event, while the receiver must interpret it in the business context. A technical scenario can fuel more activity; a seemingly secondary event can disrupt an important procedure. We need a map between scenario names and real work.

The Guide to Make for automations helps to understand the operation of flows. With the new subscriptions, the project extends to their maintenance. The goal is not to collect more error messages, but to reduce situations where a customer request remains unfollowed because the system has not completed it.

How do I get Event subscriptions notifications?

Make sends POST requests to a public HTTPS endpoint configured to receive them. The documentation describes delivery logs, status or response code and a secret signing. Signature verification is recommended to check the origin of notifications. Event subscriptions documentation.

The endpoint must exist and be ready before activation. It is not enough to paste an address: you need to know who keeps it, where it records events and what it returns to Make. If the recipient accepts the request but fails to create the alarm, the technical delivery may be different from the desired operational outcome.

It is useful to separate reception and treatment. The exposed component verifies the message and records it according to the adopted design; the internal path then decides whether to open a report, inform a contact person or update a state. This separation is an architectural proposal, not an automatic function to be attributed to beta Make.

Subscription deactivated or endpoint failure: what changes?

It's two different conditions. A subscription set to Inactive does not receive events and Make does not append them to retrieve them later. Reactivating it therefore does not mean receiving what happened during deactivation. The limit concerns the status of the subscription, not any unavailability of the recipient. Subscription Status.

If the subscription is active but the URL does not accept a delivery, Make documents up to ten retry after the first attempt, with increasing expectations. Manual attempts are also planned. This mechanism helps to handle a temporary failure, but does not amount to unlimited recovery. Logs and the outcome of deliveries must be checked. Documented retry.

Delivery can occur more than once. The receiver must therefore recognise an event that has already been handled before repeating an action, for example opening a second ticket for the same signal. This property is called idempotence: receiving a notification twice must not produce two business effects. The identifier to use must be chosen according to the data actually documented by Make.

The company must also monitor the monitoring channel. If the receiver falls, an independent control is needed that signals its unavailability. Otherwise, the system that should make errors visible becomes in turn a blind spot. An alternative channel and a periodic path verification can be part of the project.

There is also no need to confuse an absence of warnings with an absence of problems. The flow can produce a wrong result without generating the expected technical event. If a scenario inserts the data into the wrong customer, the execution might appear successful. Monitoring of business outcomes remains necessary along with that of the platform.

What warnings deserve an immediate response?

The table proposes a method of classifying alerts, without attributing each row to a product-specific event type. Before configuring subscriptions, you need to verify the events that are actually available in the current documentation and choose those that are relevant to your organization.

Priority must also be linked to the process. An internal draft may wait for an ordinary revision; an order that does not reach the management software may require timely intervention. The criterion should not be how technical the message is, but what consequence it produces at work. This choice must involve those who use automation, as well as those who built it.

Hypothetical scenario: an SME controls the passage of leads

Let's imagine a plant engineering company that uses Make to transfer requests from the site to CRM. If the flow is interrupted, the notification reaches a receiver and opens a report to the commercial and technical contact person according to an agreed rule. The message contains the process concerned, without including any unnecessary personal data.

The referent checks which requests have remained incomplete and uses a recovery procedure. It does not blindly re-launch the entire scenario: first check if some tabs have already been created. Recovery must avoid duplicates and must distinguish delivery error from already recorded data.

It's a hypothetical scenario. No response times or recovered leads are promised. The test must simulate both the failure of the scenario and the unavailability of the receiver. In this way the team verifies the entire chain, from signal to intervention, and not just the arrival of an HTTP request in the technical panel.

Hypothetical scenario: a study prepares documentary drafts

Consider a professional firm that uses an AI stream to prepare drafts from authorized documents. When a technical step fails, staff receive a report related to the practice. The notification does not contain the entire document: it indicates where to consult the information with the normal permissions of the study.

An AI service error may require a new attempt; a missing document requires a person instead. The recipient should not treat each case in the same way. The referent must see if the result is absent, partial or already available, to avoid a second unnecessary processing.

This example is also hypothetical. The quality of the draft requires checks other than the technical control of the execution. The lessons of Aqua on errors of agents in production are relevant precisely because they invite you to observe the behavior of the system, not just the existence of a response. The application to Make automations is a project analysis.

How to design the receiver without creating new risks?

Open the notification testing tab

Prepares the HTTPS endpoint, configures the secret, and verifies the authenticity of requests. Valid event proof, invalid request, internal error and receiver unavailability. Check register, alarm destination, and referent behavior. It also checks how to detect missing events through an independent check.

A public endpoint must be designed to accept only what is needed. The secret signing should not appear in logs, screenshots or messages to staff. Signature verification should be implemented by following the current instructions, without inventing a format. Reference Make.

The content of the notification must also be treated as given. It should not become a free command to run on other systems. If the recipient opens a ticket or sends an alert, the text must be constructed in a controlled manner and with minimal useful context. Integration between systems, as in management software and n8n, always requires clear boundaries on actions.

How to handle unnecessary repetitions and alarms?

A persistent problem can generate many similar reports. If staff receive a new message with no context each time, they can stop considering them. The receiver can be designed to link events to the same incident and show an understandable state, but verify which identifiers and information are really available.

Noise reduction should not hide distinct problems. A failure on the transfer of leads and one on the creation of documents can have similar causes but different consequences. Aggregation should follow the process and the person responsible, not just the text of the error. Rules should be tried with the staff receiving notices.

Finally, a verifiable closure is needed. It is not enough to mark "solved" because the scenario returns green. It is necessary to check the outstanding requests and distinguish what has been recovered from what requires intervention. The crash log may be short, but it should explain cause, action, and final control. So the next similar problem doesn't start from scratch.

Beta and plans: what to check before adoption?

The function is in beta; the documented limit is of three subscriptions for organization on Teams, while Enterprise provides for unlimited. These limits relate to subscriptions, not an unlimited promise of any resource or service. Before designing destinations you need to check your current plan and conditions. Introduction Make.

A choice can be to concentrate treatment in a recipient and distribute alerts internally, if consistent with safety and maintenance. However, it should not be chosen only to circumvent a plan limit: the component becomes an operational dependency and must be maintained. Architecture and total cost must be assessed together.

For automation alternatives, Make, Zapier and n8n offers comparison criteria. The new free shares of Logic Apps Automation concern another platform and another cost model. No list advantage replaces the verification of the alarm and recovery path.

What mistakes turn a warning into false tranquility?

The first is to deactivate a subscription by thinking of automatically recovering subsequent events, or treat the retryes of a failed endpoint as infinite. The second is to omit signature verification. The third is to send complete practice data in too wide a channel. The fourth is to associate each event with a new automatic attempt without checking the effects already produced.

A further mistake is not assigning the person responsible. "The team will receive the alert" does not clarify who should intervene, verify and close the problem. The procedure must work even when the person who built the scenario is not available. Documenting the alternative is part of the service, it is not an optional addition.

The same reasoning applies during changes in flow, such as the Zapier Agents migration. When changing steps, tools, or sources, you also need to update what you control. An alarm designed on the old process can continue to work technically and no longer describe the actual work.

How to deliver monitoring to staff?

An alarm procedure should be understandable to those who use it during a problem. The message must indicate which work is involved, where to consult the context and who can intervene. An isolated technical code forces the recipient to seek information just when action is needed. Better a brief description related to the business process.

The referent needs to know what actions they can perform and what they require support. Recovering an incomplete request is different from changing the scenario. The procedure should distinguish the two paths and indicate how to prevent different people from intervening on the same practice without coordinating. The closure must also be communicated to the head of the work.

Before delivery it is better to simulate an accident with the staff, without involving real requests. The test shall verify whether the warning reaches the correct destination, whether the context is sufficient and whether the recovery produces the expected outcome. An obstacle that emerged here is a requirement to be corrected, not a detail to be entrusted to the team's future experience.

The test must involve the actual recipient, because a correct but incomprehensible alarm still leaves the process stationary. The referent must recognize the next action without reconstructing the architecture alone.

How to start the process that can't stand still?

Choose an automation with a clear expected result and a person who can verify it. Map the technical error, the involved request and the recovery procedure. Then build and test the receiver before activation, including its unavailability in trials.

The company should receive a simple operational path: how to recognize the problem, where to read the context, what to check before relaunching and how to verify the result. The beta Make provides a new signaling channel; the value arises from the integration of that channel into daily work.

If a flow breaks and the staff only discovers it when a response to the customer is missing, Giallo can design company automations with monitoring and recovery. The starting point is the concrete error to be made visible, along with the person and the procedure that can solve it.