Loading

Create a rule and observe the alert lifecycle

In this tutorial, you'll use the experimental alerting system to detect a real-world performance problem and watch what happens next. You'll see how the system decides when a condition is serious enough to open an alert, how it tracks that alert over time, and how it closes automatically when things return to normal, without any manual intervention.

Here's what you'll do:

  1. Load sample data - Create an index and populate it with synthetic latency data that moves through healthy, degraded, and recovered phases. This gives you a realistic dataset to work with without needing a live service.
  2. Write a detection query - Use the query sandbox to build and preview an ES|QL query that computes P95 latency and flags breaches. The sandbox lets you verify the logic before the rule ever runs.
  3. Configure the rule - Set the alert condition, schedule, lookback window, and recovery behavior. You'll see how each setting shapes the alert lifecycle.
  4. Confirm the rule is running - Check the Execution history page to see that the rule is evaluating on schedule and its runs are succeeding.
  5. Watch the episode open and recover - Open the alert episode's details page to watch the episode move from pending to active as the breach persists, then close automatically when the degraded data ages out of the lookback window.

Before you start, make sure you have the following:

  • One of the following deployment types:

    • A Serverless project: This tutorial uses an Elastic Cloud Serverless project. Create a serverless project if you don't have one.
    • Elastic Cloud Hosted: An Elastic Cloud Hosted deployment running version 9.5 or later. Refer to Create an Elastic Cloud hosted deployment if you don't have one.
    • Self-managed: An Elastic Stack deployment running version 9.5 or later. Refer to the quickstart if you don't have one.
  • The experimental alerting system enabled: The feature must be turned on in your space before you can create rules or view the UI. Refer to Set up the experimental alerting system for instructions.

  • The required access: Your role must give you access to:

    Task Required privilege
    Create and manage rules Rules: All (under Alerting)
    View and triage alert episodes Alerts: Read (under Alerting); also automatically grants Elasticsearch read access to .rule-events, no separate index privilege needed
    Review execution history Execution history: Read (under Alerting)
    Create the tutorial index and load sample data create_index and write index privileges on checkout-service-logs

Before creating the rule, set up the index and load the sample data it will query.

  1. Create the index

    Run the following in Dev Tools to create the index that your rule will query. Unlike data streams, this index requires explicit creation because it uses a custom mapping.

    PUT checkout-service-logs
    {
      "mappings": {
        "properties": {
          "@timestamp": { "type": "date" },
          "service.name": { "type": "keyword" },
          "transaction.name": { "type": "keyword" },
          "latency_ms": { "type": "float" }
        }
      }
    }
    		

    Confirm the response shows "acknowledged": true before proceeding.

  2. Load the sample data

    Expand the drop-down below to copy the full bulk request, then run it in Dev Tools. It populates the index with synthetic latency data for a checkout service covering three phases:

    • Healthy (21:5722:12): P95 well under 2 seconds
    • Degraded (22:1322:27): P95 well over 2 seconds across 3 consecutive 5-minute windows
    • Recovered (22:2822:37): P95 returns to healthy levels

    The response should show errors: false for all documents.

    Note

    The timestamps are fixed to 2026-07-02, which is in the past. Before running this request, open it in a text editor and replace 2026-07-02 with today's date in YYYY-MM-DD format, keeping the time values unchanged. Once you load the data, complete the tutorial within 2 hours to see the full episode lifecycle.

You'll build a rule that detects when P95 latency for a service exceeds 2 seconds. The rule queries the synthetic data you just loaded, so you can see the breach and recovery cycle play out in real time.

  1. Open the rule editor

    Go to Alerting V2 Preview using the global search field. From the rules list, select the option to create a new rule. When the rule creation panel opens, select Create ES|QL rule to open the rule authoring flyout.

  2. Write and test the detection query

    1. Paste the following ES|QL query into the Query sandbox. It computes the 95th percentile latency per service, assigns a severity label based on the result, and filters to show only services where P95 exceeds 2 seconds. Each pipe (|) passes the output of one step to the next.

      FROM checkout-service-logs
      | STATS p95_latency_ms = PERCENTILE(latency_ms, 95) BY service.name
      | EVAL severity = CASE(
          p95_latency_ms >= 4000, "critical",
          p95_latency_ms >= 2000, "high",
          "low"
        )
      | WHERE p95_latency_ms > 2000
      		
      Note

      You don't need to add a WHERE @timestamp clause to this query. Both the query sandbox and the rule executor automatically inject the time-window filter based on the date range you select in the sandbox or the rule's schedule and lookback once it's running.

    2. Set the sandbox date range to Last 1 hour and run the query. This preset gives comfortable coverage of the full dataset without pulling in data from a previous run.

    3. Confirm the query results. You should see one row for service.name: checkout with p95_latency_ms above 2000 and severity: high or critical.

      You can also use the sandbox to preview what recovery looks like. If you narrow the range to a healthy window (before 22:13 or after 22:28), the row disappears. No rows means no breach, and when a scheduled evaluation returns the same, the episode closes. You'll configure this behavior in the Recovery Condition step.

    4. Select Apply changes to populate the rule form, then select Next.

      Note

      The sandbox time controls set the preview range only. They don't carry over to the rule's schedule or lookback window once the rule is running.

  3. Configure the alert condition

    The query you applied from the sandbox auto-fills Mode, Time field, and Group fields. Set the remaining fields:

    • Set Alert delay to Breaches: 2. The breach must persist across 2 consecutive evaluations before the episode moves to active.
    • Set Schedule to every 5 minutes.
    • Set Lookback Window to the last 2 hours. This ensures the rule can reach the pre-loaded sample data regardless of when you complete the tutorial.

    Select Next.

  4. Configure the recovery condition

    Confirm the default settings:

    • Recovery: Default recovery
    • Recovery delay: Immediate (no delay, recovers on first non-breach)

    These default settings will produce the automatic recovery behavior this tutorial demonstrates. As soon as a scheduled run returns no breaching rows, the episode will close.

    Select Next.

  5. Name and save the rule

    1. On the Details & Artifacts step, enter the following:

      • Name: Checkout Service Latency
      • Description: Detects when P95 latency for the checkout service exceeds 2 seconds. Groups by service name and assigns severity: critical at 4 seconds, high at 2 seconds.

      Select Next.

    2. On the Actions step, do not create an action policy (rules can run without notifications or an action policy configured). Select Create rule to create and enable the rule.

The sandbox showed that your query can find a breach. This step confirms the rule is actually running on schedule. The Execution history page gives you a real-time log of every rule run and its outcome.

  1. Open Execution history using the global search field.

  2. Select the Rules tab and use the Rule filter to select Checkout Service Latency.

  3. Wait one schedule interval (5 minutes) after saving the rule, then check the table for a recent entry.

  4. Confirm the Response shows success and the Timestamp matches a recent time. If no entries appear, confirm at least one 5-minute interval has elapsed since you saved the rule.

With the rule running, you can watch the full alert lifecycle play out on the Alerts page and in the episode detail view. The episode opens once the breach persists across consecutive evaluations, stays active while the degraded data is in the lookback window, and closes automatically when no breaching data remains.

Note

Because you set Alert delay to 2 consecutive breaches, the episode starts as pending and only moves to active once the breach persists across a second evaluation. This prevents transient spikes from opening an episode right away.

  1. Open Alerting V2 Preview using the global search field and go to the Alerts page.

  2. Filter by Rule to show only episodes for Checkout Service Latency. After the first two evaluations (about 10 minutes), you'll see an episode appear and move from pending to active.

  3. Select the episode to open its details page. Use the metric trend to see how P95 latency compared to the threshold over the episode's lifetime, and confirm the grouping value (checkout) that triggered it.

  4. Wait for the rule's lookback window to advance past the degraded data. Once no breaching rows fall within the 2-hour window, the episode status changes to inactive automatically. No manual action is required. This is default recovery in action.

This tutorial put four core concepts into practice:

  • Rules - The query you wrote runs every 5 minutes and computes P95 latency over a 2-hour lookback window. Each run checks whether the result exceeds 2000 ms. The schedule and lookback you configured determined how often the rule checked and how much history it analyzed each time.
  • Severity tiers - The CASE() expression you wrote classified each breach as high or critical based on the P95 value. Those labels are stored in .rule-events and visible in the episode detail view.
  • Episode lifecycle - Setting Alert delay to Breaches: 2 meant the episode didn't open on the first breach. You watched it start as pending on the Alerts page, then move to active after a second consecutive breaching evaluation confirmed the condition wasn't transient.
  • Automatic recovery - Because you kept the default recovery settings, the episode closed on its own once the degraded data aged out of the lookback window. The rule detected the absence of a breach and moved the episode to inactive.