Create Notification Profiles for Incidents
| Where Can I Use This? | What Do I Need? |
|
|
- One of the following licenses:
|
- From the Incidents > Incidents > Notification Profiles page, select Create
Notification Profile.
Enter the profile name and description.
The default profile receives Informational alerts for the tenant. In
other notification profiles, you can elect to receive informational alerts or
not.
Under RECIPIENTS, select Email or Webhooks.
To use Email, enter a valid Email Name and Email
Addresses. You can add multiple email addresses separated by a comma.
Send Test
Mail verifies that your email notification
profile can successfully deliver messages before you deploy it in
production.
Webhooks are custom HTTP callbacks that you define. They are
triggered by an event, such as pushing code to a repository or posting a
comment on an issue. When the event occurs, the source app makes an HTTP
request to the URI configured for the webhook. To use
Webhooks:
Enter a webhook name and a valid URL.
Under Auth Type, select None,
Basic, or
Token.
None—You don’t need to add any more
information.
Basic—Enter the username and password of the
webhook.
Token—Enter the webhook token.
- Test
Webhook Connection to send an on-demand
test payload directly from your webhook configuration, providing
immediate confirmation that your integration works before an actual
incident occurs.
Save Profile.
Webhook Connectivity Validation
The Test Webhook feature in Strata™ Cloud Manager verifies URL
reachability, authentication correctness, and receiver compatibility by sending a
single synthetic payload to your configured endpoint. To prevent invalid requests,
the Test Webhook button activates only when your configuration form contains
a URL and all required authentication fields.
The validation process includes the following components and behaviors:
Test payload—Uses synthetic data that matches the production
webhook schema. Downstream systems can easily identify the payload as test
data to avoid triggering operational workflows.
Authentication validation—Uses the exact credentials and
headers from your current, unsaved form values (None, Basic, or Bearer) to
verify endpoint acceptance before you save the profile.
Test execution and results—Sends a single, non-retried HTTP
POST request to the specified URL. Success or failure details (such as HTTP
status codes or error categories) display directly in the web interface,
allowing you to iteratively test configuration changes without committing
them.
Email Notification Profile Validation
The Test Email action verifies that your email notification profile can
successfully deliver messages before you deploy it in production, preventing silent
failures caused by incorrect addresses, authentication issues, or connectivity
problems.
The validation process includes the following behaviors:
Validation execution—Sends a test message to every recipient
address in your profile using the production delivery path. The system
returns a per-recipient result indicating whether the provider accepted or
rejected the message.
Provider acceptance versus inbox delivery—Confirms your
configuration is correct and the email provider accepted the message.
Because downstream factors (such as spam filters or storage quotas) might
still prevent inbox delivery, the delivery result of the test message is
displayed on the UI.
Profile configuration—Operates independently of the profile
save action, allowing you to test iteratively without committing changes. To
prevent delivery attempts to malformed entries, the Test Email button
only activates when your profile contains at least one syntactically valid
email address.