Skip to main content

Create and Manage Alerts

This is the primary configuration guide for Alerting. It walks through building an alert in the Developer Portal, the same places the left nav lists under Alerting.


What you will configure

Three portal areas: Notification channels, Alert configurations, then Alert logs. Field meanings: Concepts.


Configuration flow at a glance

YouDeveloper PortalMonitoring1. Create notification channel12. Create alert configuration + attach channel23. Leave rule Enabled34. ChainIT evaluates every minute4When it fires5. Alert log + notify56. Acknowledge / Resolve log6
  1. Create at least one notification channel.
  2. Create an alert configuration and attach that channel.
  3. Leave the rule Enabled.
  4. Watch Alert logs when something fires.
  5. Acknowledge or Resolve logs as your team handles them.

Portal areas

#AreaPurposeNav path
1Notification channelsEmail or webhook destinationsAlerting / Notification channels
2Alert configurationsMonitoring rulesAlerting / Alert configurations
3Alert logsHistory of firings + triageAlerting / Alert logs

Step 1: Create a notification channel

1
Open Alerting / Notification channels and create a channel
1

Give the channel a clear name your team will recognize.

2

Choose Email or Webhook (see tabs below).

3

Save: you can reuse this channel on many alert rules.

  1. Choose Email.
  2. Add one or more recipient addresses.
  3. Save.
Create the channel first

The alert configuration form asks you to attach a channel. Create at least one email or webhook channel before you start a new alert configuration.


Step 2: Create an alert configuration

Open Alerting / Alert configurations, then create or add a new rule.

2
Basics
1

Name: something your team will recognize later

2

Application: the app whose traffic to watch

3

Category: API or Webhook

4

Description (optional): why this rule exists

5

Severity: triage urgency (does not change the math)

3
Metric and condition
1

Metric: what to measure

2

Aggregator: how to combine minute values (Maximum, Average, and similar)

3

Operator + Threshold: comparison and limit

4

Time window: 15 / 30 / 45 minutes

Write the condition as a plain sentence before you save:

“If the maximum API request count in the last 15 minutes is greater than 1000, warn the team.”

Rate thresholds use decimals

For rate metrics (error rate, success rate, and similar), enter 0.15 for 15%, not 15. See Concepts: Threshold.

Count aggregator is easy to misread

Aggregator Count counts minute samples, not total API calls. For traffic volume prefer Maximum or Average. See Concepts: Aggregator.

4
Filters (optional) and notifications
1

Add filters only if you need to narrow traffic (method, endpoint, status, subscription).

2

Attach one or more channels from Step 1.

3

Optionally set a subject and short description for the message.

4

Save and leave the rule Enabled.

Reference: Concepts: Filters.

One clear rule first

Start with a single rule and one channel. Confirm you receive a notification and see an alert log, then add more rules or tighter filters.


Example rules you can copy

FieldValue
CategoryAPI
MetricAPI request count
Combine withMaximum
OperatorGreater than
Threshold1000
Window15 minutes
FilterMethods GET and POST
ChannelOps email

Edit, pause, or delete a rule

From Alerting / Alert configurations:

ActionWhen to use it
EditChange threshold, filters, channels, or severity
DisableTemporarily pause monitoring without losing the rule
EnableResume monitoring
DeleteRemove a rule you no longer need

Manage alert logs

When a rule fires, an entry appears under Alerting / Alert logs.

StatusMeaning
ActiveNewly triggered
AcknowledgedSomeone is handling it
ResolvedClosed by your team
  1. Open the log entry.
  2. Update status as your incident process requires.
  3. Remember: healthy traffic later does not auto-resolve old logs.

More detail on statuses is in the table above. Use the portal Alert logs list to triage firings.


Tips for good alerts

  1. Prefer rules that map to a real action (page someone, open a ticket, investigate).
  2. Use filters when one noisy endpoint would otherwise dominate.
  3. Keep thresholds realistic for your normal traffic.
  4. Use severity consistently so on-call knows what is urgent.
  5. Review alert logs after the first few firings and tune the rule.

Next steps

Next steps
  1. Concepts

    metrics, aggregators, thresholds, filters, severity

  2. Overview

    end-to-end flow and what you can monitor