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.
For Auth Type, select
None, Basic,
or Bearer.
None—You don’t need to add any more
information.
Basic—Enter the username and password of the
webhook.
Bearer—Enter the webhook token.
(
Optional) In the
Webhook Signing
Secret field,
Generate
Secret. Strata Cloud Manager generates a
cryptographic signing secret and displays it in cleartext. If a
secret already exists, the field displays a masked value. See
Signed Webhook Deliveries.
Copy the secret to your clipboard.
You can only view and copy the
secret at the time of generation or rotation. After you navigate
away or refresh the page, you cannot retrieve the secret
again.
(Optional) Rotate Secret to
generate a new signing secret if you want to replace the
existing one.
Strata Cloud Manager generates a new signing secret and displays
it in cleartext. Copy to save the new
secret. The previous secret remains valid for 72 hours after
rotation. During this grace period, Strata Cloud Manager
includes signatures for both the new and previous secrets in
each webhook delivery, so your endpoint can validate using
either secret. After 72 hours, the previous secret expires
automatically and only the new secret produces valid signatures.
Update your receiving endpoint to use the new signing secret
within the 72-hour grace period. You must save the notification
profile after you generate or rotate the signing secret for the
change to take effect.
Test
Webhook Connection to verify your
integration by sending an on-demand payload. This ensures the
connection works before production incidents trigger
notifications. When a secret is newly generated and visible in
the interface, Strata Cloud Manager calculates an HMAC signature
using this unsaved secret and includes it in the request header.
You can use this cleartext secret to validate the HMAC on your
endpoint, confirming the secret works before you save the
profile.
For profiles with an existing (masked) secret, the test delivery
includes one signature, or two if a previous secret remains
within the 72-hour grace period. Use the signing secret you
previously saved to compute an HMAC and compare it against the
header values to verify the accuracy of your stored secret.
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.
