Create your first alert

An alert should tell you when something needs attention and give you a reason to act. Start with a symptom your users experience, such as slow requests or a rising error rate. Keep signals that only help diagnose a problem in dashboards.

Use the same everr/ directory and Cloud session from your first dashboard. The rule becomes a file you review alongside your code.

Use your coding agent

Ask your agent to choose a signal and threshold from your app's data:

/everr-setup-resources Suggest one actionable alert from this app's production telemetry in Everr Cloud. Use the observed baseline, explain when I should act, and preview the rule before publishing.

The agent checks available signals, writes the rule, tests its query, and stages a preview. Review why it fires and what you would do in response.

Write it manually

The example below builds on the dashboard's request latency signal. It alerts when p99 latency exceeds 500ms across at least 100 successful requests in the last 5 minutes, with the breach lasting 2 minutes before firing.

The threshold and minimum request count are examples. Adjust both to your traffic and latency goals before publishing. The query counts recorded server spans, so sampling affects this minimum. Replace my-service with the same service name used in your dashboard.

Save this as everr/api-latency.alert.yaml:

kind: AlertRule
metadata:
  name: api-latency
spec:
  display:
    name: Slow API requests
    description: Sustained high p99 latency for successful server requests.
  evaluationInterval: 1m
  for: 2m
  resolveAfter: 2
  instanceLabels: [ServiceName]
  notificationMessage:
    title: "${ServiceName} requests are slow"
    description: "p99 latency is ${value}ms over the last 5 minutes"
  condition:
    operator: gt
    threshold: 500
  query: |
    SELECT
      ServiceName,
      count() AS requests,
      round(quantile(0.99)(Duration) / 1e6, 1) AS p99_ms,
      if(requests >= 100, p99_ms, 0) AS value
    FROM traces
    WHERE ServiceName = 'my-service'
      AND Timestamp >= now() - INTERVAL 5 MINUTE
      AND SpanKind = 'Server'
      AND StatusCode != 'Error'
      AND toString(ResourceAttributes.`deployment.environment.name`) = 'production'
    GROUP BY ServiceName

The SQL returns the measured signal as a numeric value; condition decides whether it breaches. Returning non-breaching values keeps the signal visible when the alert is healthy.

• instanceLabels identifies the alert instance by service. Keep identities stable between evaluations.
• evaluationInterval runs the query once a minute. for waits for a sustained breach, and resolveAfter requires two consecutive non-breaching evaluations before resolving.
• notificationMessage can use columns returned by the query, including ${value}.
• The request-count guard avoids paging on a percentile from too few requests. Low or missing traffic needs its own signal if that should alert.

This rule uses the same server, environment, and status filters as the dashboard. See the AlertRule spec for all fields, and Writing good alerts for signal selection.

Preview the rule

everr apply ./everr --preview

Open the printed Preview: link and go to Alerts. Preview rules evaluate against real data but do not send notifications. Check the measured value, threshold, and evaluation state. If the query fails or returns no expected data, fix the file and preview again.

Connect notifications

Open Notifications in Everr Cloud and create a channel for Slack, Discord, Telegram, or an HTTPS webhook. Your first channel becomes the organization's default destination. See Set up alert notifications for configuration.

You can see an alert's state in the UI without a channel. A channel is needed to receive its notifications.

Publish and check

When the preview and destination are ready:

everr apply ./everr

Review the plan and confirm. Open Alerts, find Slow API requests in the rules list, and check its detail page for the signal history, threshold, and evaluation health.

Edit the file when you need to tune the rule, then preview and apply the whole directory again. Keep the same project and slug to update it in place. Notifications follow alert transitions rather than every evaluation.

Next: Add a runbook so the alert leads to a concrete response.