One of the most common questions users ask is:

"I sent data to CriticalBuzzer, but I didn't receive any alert."

In almost every case, there is a logical explanation.

This guide walks through every stage of the event processing pipeline and explains why a monitor may not trigger, why an alert may be intentionally suppressed, or why notifications may not be delivered.

How CriticalBuzzer Processes an Event

Every event passes through multiple stages before an alert is sent.

Application
      │
      ▼
HTTP POST
      │
      ▼
Authentication & Validation
      │
      ▼
Project / Monitor Status Checks
      │
      ▼
Rule Evaluation
      │
      ▼
Anomaly Detection (if enabled)
      │
      ▼
AI Evaluation (if required)
      │
      ▼
Decision Engine
      │
      ▼
Notification Router
      │
      ▼
Email / Slack / Telegram / Discord / Push / Webhook

An event can be rejected or intentionally stopped at any stage.

1. The Event Never Reached CriticalBuzzer

If CriticalBuzzer never successfully accepted your event, monitoring cannot occur.

Invalid Endpoint Credentials

Every ingestion endpoint contains both an Alert ID and an Endpoint Secret.

Example:

POST /a/{alert_id}/{endpoint_secret}

If either value is incorrect, CriticalBuzzer rejects the request.

Typical response:

HTTP 403 Forbidden

How to fix

• Verify the Alert ID
• Verify the Endpoint Secret
• Ensure you're posting to the correct environment

IP Whitelist Rejected the Request

If IP Whitelisting is enabled, only approved IP addresses may send events.

Requests from any other IP are rejected.

Typical response:

HTTP 403 Forbidden

How to fix

• Add your server IP to the organization whitelist
• Verify your server's public IP address
• Remove IP restrictions if they are not required

Invalid or Revoked API Key

When using API Key authentication:

• Missing key
• Invalid key
• Revoked key
• Key belonging to another organization

will cause authentication failure.

Typical response:

HTTP 401 Unauthorized

or

HTTP 403 Forbidden

How to fix

Generate a new API key and update your application.

Malformed JSON

CriticalBuzzer only accepts valid JSON.

Example of invalid JSON:

{
  "cpu": 82,

Typical response:

HTTP 400 Bad Request

How to fix

Validate your JSON before sending.

Organization Usage Limit Reached

If your organization has exceeded its monthly event quota, new events are rejected.

Typical response:

HTTP 429 Too Many Requests

How to fix

• Upgrade your plan
• Wait until the quota resets
• Reduce event volume

2. The Monitor Was Intentionally Suppressed

Sometimes the event arrives successfully but the monitor is intentionally prevented from triggering.

Monitor Is Paused

Paused monitors do not evaluate incoming events.

Incoming data may still be stored, but no alert is generated.

How to fix

Resume the monitor.

Monitor Is Disabled or Archived

Disabled or archived monitors ignore all incoming events.

How to fix

Enable the monitor.

Parent Project Is Paused

Projects override monitor behavior.

If a project is paused, every monitor inside it is automatically paused.

How to fix

Resume the project.

Monitor Is Muted

Users can temporarily mute a monitor.

Examples:

• Mute for 1 hour
• Mute until tomorrow
• Mute during maintenance

Events continue arriving, but notifications are intentionally suppressed.

How to fix

Wait until the mute expires or manually unmute the monitor.

Cooldown Window

To prevent alert storms, CriticalBuzzer applies a cooldown period after a trigger.

Example:

CPU > 90%

09:00 Trigger

Cooldown = 10 minutes

09:03 CPU = 94%
→ Suppressed

09:07 CPU = 96%
→ Suppressed

09:11 CPU = 93%
→ New alert allowed

This prevents dozens of identical notifications.

Duplicate Event Detection

CriticalBuzzer detects identical events arriving repeatedly within a short period.

Instead of repeatedly evaluating the same payload, duplicate events are intentionally suppressed.

This reduces unnecessary processing and duplicate notifications.

3. Rule Evaluation Failed

The monitor evaluated the event successfully but determined that the trigger condition was not met.

Threshold Was Not Reached

Example rule:

cpu_usage > 80

Incoming payload:

{
    "cpu_usage": 75
}

Since 75 is not greater than 80, the monitor behaves correctly by not triggering.

Required Field Missing

Example rule:

Monitor field:
cpu_usage

Incoming payload:

{
    "memory": 80
}

The required field does not exist.

CriticalBuzzer cannot evaluate the rule.

Field Is Not Numeric

Example:

{
    "cpu_usage": class="hljs-string">"high"
}

Numeric comparison cannot be performed.

The event is ignored.

Field Name Mismatch

Configured field:

cpu_percent

Incoming payload:

{
    "cpu": 92
}

Although the value is present, the configured field name does not match.

This is one of the most common configuration mistakes.

Always verify that your payload field names exactly match the configured monitor field.

4. Anomaly Detection Did Not Consider It Abnormal

This section applies only to Anomaly Monitors.

Unlike threshold monitors, anomaly monitors learn normal behavior over time.

Deviation Was Too Small

CriticalBuzzer calculates how unusual a new value is.

If the deviation is very small, it is considered normal system variation.

Example:

Normal CPU

58
60
61
59
60

New value

62

This small increase is expected and does not qualify as an anomaly.

AI Determined It Was a False Positive

Borderline anomalies are reviewed by the AI evaluation engine.

Example:

Traffic increased by 20%

The AI may determine:

• Marketing campaign launched
• Scheduled batch job
• Expected business spike
• Daily traffic pattern

Instead of notifying you unnecessarily, the AI classifies the event as a false positive and suppresses the alert.

This helps reduce alert fatigue while still surfacing meaningful incidents.

5. The Monitor Triggered but No Notification Was Delivered

Sometimes the monitor triggers successfully, but notifications cannot be sent.

No Notification Channel Enabled

A trigger occurred, but every delivery channel is disabled.

Examples:

• Email OFF
• Slack OFF
• Telegram OFF
• Push OFF
• Discord OFF

The alert exists, but there is nowhere to send it.

Notification Integration Is Not Configured

The notification channel is enabled, but its credentials are missing or invalid.

Examples include:

• Missing Slack Webhook URL
• Invalid Telegram Bot Token
• SMTP configuration errors
• Expired API credentials

CriticalBuzzer cannot deliver the notification until the integration is correctly configured.

Duplicate Notification Protection

To prevent users from receiving identical notifications repeatedly, CriticalBuzzer applies idempotency protection.

If an identical notification for the same event has already been delivered to the same channel, duplicate deliveries may be skipped.

6. Infrastructure or System Issues

In rare cases, infrastructure problems may temporarily delay or prevent alert processing.

Background Workers Are Offline

CriticalBuzzer uses background workers to process incoming events and evaluate monitors.

If these workers stop running:

• Events remain queued
• Evaluations do not occur
• Alerts are delayed until workers resume

Redis Queue Unavailable

Incoming events are placed into a Redis-backed processing queue.

If Redis is unavailable:

• Events cannot enter the processing pipeline
• Monitor evaluation cannot begin
• Alerts cannot be generated

Troubleshooting Checklist

If your monitor didn't trigger, work through this checklist in order:

• ✅ Did the HTTP request return a successful response?
• ✅ Was authentication successful?
• ✅ Is the monitor enabled?
• ✅ Is the project active?
• ✅ Is the monitor currently muted?
• ✅ Is the monitor inside a cooldown period?
• ✅ Does the payload contain the correct field?
• ✅ Is the field numeric (when required)?
• ✅ Did the value actually satisfy the rule?
• ✅ If using anomaly detection, was the deviation significant?
• ✅ Did AI classify the event as a false positive?
• ✅ Is at least one notification channel enabled?
• ✅ Are notification integrations configured correctly?
• ✅ Are background workers and Redis operating normally?

Our Recommendation

Most "missing alerts" are caused by configuration rather than system failures.

When troubleshooting:

1. Verify that the event was accepted.
2. Confirm the monitor and project are active.
3. Ensure the payload matches the configured monitor field.
4. Verify the trigger condition was actually met.
5. Check notification channel configuration.
6. Review the monitor's event history and evaluation logs for the exact reason an event was accepted, suppressed, or rejected.

Following these steps will quickly identify why a monitor did not trigger and help restore expected alerting behavior.