Alerts

Alerts watch your metrics and tell you when something crosses a line. You define the metric, the condition, the threshold, and how long it must persist before firing. JuhJuh evaluates your rules on every metric ingestion batch, so notifications arrive within seconds of a threshold breach.

No polling delay. No cron-based evaluation. Alerts fire as data flows in.

How alerts work¶

graph LR
    M[Metrics Ingested] --> E[Alert Rules Evaluated]
    E -->|threshold crossed| C{Duration met?}
    C -->|yes| N[Notification Sent]
    C -->|no| W[Continue Watching]
    N --> Email[Email]
    N --> Slack[Slack]
    N --> Webhook[Webhook]

1. Your application sends metrics to the ingestion endpoint
2. On every batch, JuhJuh evaluates all active alert rules against the new data
3. If a metric crosses its threshold, JuhJuh checks whether the condition has persisted for the configured duration
4. If the duration requirement is met, the alert fires and notifications are sent to your configured channels

Creating an alert rule¶

1. Open Observability in your dashboard
2. Go to the Alerts tab
3. Click Create Alert
4. Fill in the alert configuration:

1. Click Save

The rule is active immediately. JuhJuh starts evaluating it on the next metric batch.

Example rules¶

Conditions¶

Three comparison operators are available:

Greater than is the most common condition. Use it for resource exhaustion (high CPU, high memory), error spikes, and queue buildup.

Less than is useful for availability monitoring. If a metric that should always be positive drops to zero or near-zero, something has likely stopped working.

Equal to is a niche condition for exact-match scenarios, like a connection pool count hitting zero.

Duration windows¶

The duration field prevents false alarms from transient spikes. A CPU spike to 95% for 3 seconds during a deployment is normal. A CPU spike to 95% for 10 minutes is a problem.

Choose a duration that filters out normal fluctuations but catches real incidents. For most infrastructure metrics, 5 minutes is a good starting point. For application-level error counts, immediate (0 seconds) or 1 minute is more appropriate.

Notification channels¶

When an alert fires, JuhJuh sends notifications to one or more channels.

Email¶

Sends an email to the configured address with the metric name, current value, threshold, and a link to the observability dashboard.

Slack¶

Posts a message to a configured Slack channel. Requires a Slack integration connected to your organization. The message includes the alert details, current metric value, and a direct link to investigate.

Webhook¶

Sends an HTTP POST to a URL you specify. The payload includes:

json { "alert_name": "High CPU Usage", "metric_name": "system.cpu.percent", "condition": "greater_than", "threshold": 85, "current_value": 92.3, "duration_seconds": 600, "fired_at": "2026-04-09T14:30:00Z", "organization": "your-org" }

Use webhooks to integrate with PagerDuty, Opsgenie, custom dashboards, or any system that accepts HTTP callbacks.

Managing alerts¶

Viewing active alerts¶

The Alerts tab shows all configured rules with their current status:

Editing a rule¶

Click any alert rule to update its condition, threshold, duration, or notification channels. Changes take effect on the next metric evaluation cycle.

Disabling a rule¶

Toggle a rule's active status to pause evaluations without deleting the configuration. Useful during planned maintenance or deployments when you expect temporary threshold breaches.

Deleting a rule¶

Delete a rule to permanently remove it and stop all evaluations. This action cannot be undone. If you might need the rule again, disable it instead.

Alert best practices¶

Start broad, then narrow¶

Begin with a few high-level alerts that catch major issues:

1. CPU above 90% for 5 minutes: catches runaway processes and undersized infrastructure
2. Memory above 90% for 5 minutes: catches memory leaks and large allocations
3. Error count above 50 per batch: catches application-level failures
4. Queue depth above 500 for 5 minutes: catches processing bottlenecks

After running these for a week, review which alerts fire and adjust thresholds based on your application's normal behavior.

Avoid alert fatigue¶

Every alert should require action. If an alert fires and the response is "ignore it," either raise the threshold, extend the duration, or delete the rule. Alert fatigue is the enemy of effective monitoring. When your team starts ignoring alerts, real incidents get lost in the noise.

Use duration windows¶

Immediate alerts (duration 0) should be reserved for conditions that always indicate a problem. For everything else, require at least 1 to 5 minutes of sustained breach. This eliminates false positives from deployment-time spikes, garbage collection pauses, and normal load fluctuations.

Combine with dashboards¶

Alerts tell you something is wrong. Dashboards tell you why. When an alert fires, click through to the metrics dashboard to see the trend, then check traces and logs for the root cause.

Infrastructure alerts¶

If your application runs on JuhJuh-managed VMs, infrastructure metrics (CPU, memory, disk, network) are collected automatically. You can set alert rules on these metrics without any application-level instrumentation.

Common infrastructure alert configurations:

Related¶

• Observability for an overview of all observability signals
• Metrics for understanding metric types and ingestion
• Instrumentation for connecting your application to send metrics
• Logging for investigating issues when an alert fires
• Tracing for following specific requests during an incident
• Slack for configuring Slack notification channels