Build an incoming-webhook automation

Capture a sample and test your conditions before enabling real actions.

Capture a sample

Open Automations, create a draft and open Inputs. Send an example event to the test webhook URL. Treat that address as a secret. A capture shows the fields that actually arrived; Net360 does not assume every sender uses the same structure.

Choose values for both sides

Add a condition. Either side can use a literal, a trigger field, a reusable value or output from an earlier step. Inspect the sample value and its path. Combine comparisons with AND inside a group and OR between groups. Missing data is not automatically an empty string or zero.

Identify a case and its recovery

Choose a correlation value that stays the same for the same device or service. Define start and recovery conditions from actual events. A recovery requires the same identifier and a payload the sender really emits. Do not invent a resolved event if the platform never sends one.

Wait and escalate

A workflow can wait, read other data, send a notification or create an internal automation incident. For example: match a problem, wait ten minutes, then notify if a matching recovery has not closed that case. Another wait can lead to another action. These incidents are separate from monitor outages and public status-page incidents.

Test before publishing

Use Test with captured or edited data. The isolated test does not deliver real alerts or open real incidents. Check both branches, missing fields and recovery. Save the draft before leaving; publish only when live events should execute actions. Keep the live webhook address private.

Current limits

Incoming webhooks are available. Email input still requires receiving-address setup and is inactive in this preview. Monitor-event triggers are unavailable. Verification, field structure and recovery depend on the sender.