Configuring Alerts and Notifications

Alerts tell you when something goes wrong without you having to go and look. A file transfer starts failing, an API returns errors, a scheduled job stops running — an alert notices and emails the people who need to know.

There are two halves, and you need both.

Part	What it is
Notification channel	Who gets told: a named group of email addresses
Alert	What to watch for, and which channel to notify

Channels come first. An alert has to point at a channel that already exists, so set up the channel before creating alerts that use it.

Set up in this order

1. Create the channel, so there is somewhere to send to.
2. Decide the type, based on what you are actually watching.
3. Create the alert, pointing at that channel.
4. Check the defaults that were used, and adjust anything that matters.
5. Test it by making the condition happen, and confirm the email arrives.

Create a notification channel

A channel is a name and a set of email addresses. Give it a meaningful name and reuse it across every alert that should reach those people. Change who is in the channel once, and every alert follows.

Create a notification channel called SupportTeam with alice@example.com and bob@example.com.

Add carol@example.com to the SupportTeam channel.

List the notification channels.

Channels are always referred to by name.

Choose the alert type

This is the part worth getting right. The types are not interchangeable, because they watch fundamentally different things.

Type	Watches	Use it when
Schedule	Scheduled job metrics	A scheduled job stops running, or runs too few times
Batch	Batch processing metrics	Batch volumes fall outside what you expect
REST Client	HTTP error codes from API calls	An API you call starts returning errors
SFTP	File transfer failures	SFTP transfers start failing
ABS	File transfer failures	Azure storage transfers start failing

If you do not name a type, NxAgent asks before doing anything. It never picks for you: substituting one type for another produces an alert that silently watches the wrong thing.

Create an alert

Create a schedule alert for the Orders application — notify SupportTeam if the job runs fewer than 5 times.

Create a REST Client alert on the Payments application for 500 errors, notifying DataOps.

What you are asked for

Some settings have no safe default, so NxAgent asks rather than guessing. What it asks depends on the type.

Type	You are always asked for
Schedule and Batch	Name, application, what is monitored, the comparison, the threshold, and the channel
REST Client	Name, application, which error codes, the error threshold, check frequency, how far back to look, the cooldown, and the channel
SFTP and ABS	Name, application, and the channel

The comparison direction is always asked. "Alert me if runs go below 5" and "above 5" are opposite alerts, so there is no sensible default to assume.

For REST Client alerts, NxAgent suggests reasonable starting numbers so you can accept them rather than inventing figures. It still asks, and does not apply them silently.

Everything else gets a default, and NxAgent tells you which defaults it used. You can override any of them by saying so.

How you know it worked

The alert appears in the alert list with its type and channel. The real confirmation is a test: make the condition happen and check that the email arrives at the channel.

When it does not work

Symptom	Cause	What to do
The alert cannot be created	The channel it names does not exist	Create the notification channel first, then retry
An alert never fires	The comparison direction is inverted	Check whether the threshold should be above or below, and update it
No email arrives	The channel has the wrong addresses	List the channel and confirm its members

Next steps

• Investigating Integration Health — ask what went wrong once an alert fires.
• Operating and Monitoring — the monitoring reference.