Skip to main content

Alerting Overview

Alerting provides a proactive monitoring mechanism for tracking your application's API and webhook activity and identifying abnormal or potentially critical behavior based on predefined thresholds.

It enables development and operations teams to continuously monitor important traffic and performance indicators, including:

  1. Increased API or webhook error rates
  2. Degraded or unusually slow API response times
  3. Unexpected spikes or sudden changes in traffic volume
  4. API or webhook activity exceeding configured limits
  5. Other application activity patterns that require operational attention
Configuration first

This section is for setting up alerts in the portal, not for partner /public-api calls. Start with Create and manage alerts (channel, rule, enable, logs). Use Concepts when a configuration field needs a deeper definition.

Choose your path

Click a card to jump. Prefer configuring first? Open Create and manage.

Create and manageChannel, rule, enable, logs. Start here to configure alerts in the portal.
ConceptsMetrics, aggregators, thresholds, filters, and severity: configuration field reference.

Configure in the Developer Portal​

Follow these numbered steps in the portal UI:

  1. Sign in to the Developer Portal.
  2. Open Alerting in the left sidebar.
  3. Create a Notification channel (email and/or webhook).
  4. Create an Alert configuration, attach the channel, and leave it Enabled.
  5. When a rule fires, triage it under Alert logs.

Full click-path, configuration fields, and copy-paste examples: Create and manage alerts.

End-to-end flow​

How traffic becomes a notification:

Your trafficChainITYour teamAPI / webhook activity1Enabled rules checked about once a minuteMeasure, combine, compare threshold2If threshold crossedCreate Alert log3Email / webhook (unless cooldown)4If still below thresholdKeep monitoring: no log, no notify

What that means in order​

  1. You create a notification channel (email or webhook).
  2. You create an alert rule and attach that channel.
  3. While the rule is Enabled, ChainIT reviews matching traffic about once a minute.
  4. If the condition is met, an alert log is created and channels can be notified.
  5. A short cooldown reduces notification spam if the condition stays true.

More detail: Create and manage alerts.

What you can monitor​

AreaExamples
APIRequest volume, errors, success rate, latency, payload size, rate-limit style responses
WebhookDelivery volume, success/failure rate, retries, pending deliveries, payload size

The pieces of an alert​

Think of an alert as a simple sentence:

If this metric (for this app, with optional filters) over this time window, compared with this threshold, then notify these channels.

#PiecePlain meaning
1ApplicationWhich app’s traffic to watch
2Category & metricWhat to measure (for example API error rate)
3ConditionHow to combine values over time, and what limit triggers the alert
4Time windowHow far back to look (15, 30, or 45 minutes)
5Filters (optional)Narrow the traffic (for example only POST calls)
6SeverityHow serious the alert should appear
7Notification channelsWhere to send the message (email and/or webhook)

Field definitions: Concepts.

Suggested reading order​

OrderGuideWhy
1Create and manage alertsStart here: portal configuration
2ConceptsMetrics, aggregators, thresholds, filters

Quick example​

Warn the team if any minute in the last 15 minutes has more than 1000 GET/POST API requests.

SettingChoice
CategoryAPI
MetricAPI request count
How to combine valuesMaximum (peak minute)
Compare withGreater than 1000
Time window15 minutes
FilterMethod is GET or POST
ChannelYour ops email channel
Start simple

Create one clear rule for a real pain point (errors or latency), attach one channel, enable it, then refine filters and thresholds after you see the first alert logs.

Next steps​

Next steps
  1. Create and manage alerts

    build your first channel and rule

  2. Concepts

    field reference for configuration