Skip to content

DOCS-780 - Real-time sched search deprecation #5215

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 18 commits into from
May 5, 2025
Merged
Show file tree
Hide file tree
Changes from 12 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions blog-service/2021/12-31.md
Original file line number Diff line number Diff line change
Expand Up @@ -618,13 +618,13 @@ Update - [Scheduled View](/docs/manage/scheduled-views "Scheduled Views") quer
---
## March 16, 2021 (Alerts)

Update - We have resolved a discrepancy in the notification payload of [Real Time Scheduled Searches](/docs/alerts/scheduled-searches/create-real-time-alert).
Update - We have resolved a discrepancy in the notification payload of Real-Time Scheduled Searches.

Previously, the payload for subsequent real time alerts in a given time range would incrementally report the results and omit the records that were already present in the previous alert.

For example, if the Scheduled Search initially returned 10 records, the first alert notification would contain 10 records in the payload. If the next run contained the same 10 records plus 1 additional, the notification payload would only contain the single new record.

Going forward, we will ensure that the records sent in the notification payload will always contain all the records returned in the Scheduled Search. Following the above example, the next run of the Real Time Scheduled Search would return 11 records. This change ensures that the payload will always match the results of the search in Sumo Logic.
Going forward, we will ensure that the records sent in the notification payload will always contain all the records returned in the Scheduled Search. Following the above example, the next run of the Real-Time Scheduled Search would return 11 records. This change ensures that the payload will always match the results of the search in Sumo Logic.

---
## March 12, 2021-12 (Collection)
Expand Down
40 changes: 20 additions & 20 deletions blog-service/2024/12-31.md

Large diffs are not rendered by default.

19 changes: 19 additions & 0 deletions blog-service/2025-05-15-alerts.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,19 @@
---
title: Real-Time Scheduled Searches Fully Deprecated (Alerts)
image: https://help.sumologic.com/img/sumo-square.png
keywords:
- alerts
- scheduled searches
- monitors
hide_table_of_contents: true
---

As of today, all remaining Real-Time Scheduled Searches have been automatically converted to 15-minute schedules. The ability to create or run Scheduled Searches with real-time frequency is no longer supported.

Key details:
* Real-Time frequency is no longer available in Scheduled Search creation or editing workflows.
* Any previously existing Real-Time Scheduled Searches now run on a 15-minute schedule.
* Each conversion has been recorded as an audit log event in your account.
* A small number of accounts with approved exceptions remain unaffected.

For real-time alerting, use [Monitors](/docs/alerts/monitors/overview), which provide richer capabilities such as multiple trigger conditions, alert grouping, and AI-driven insights. Learn more: [Deprecation of Real-Time Scheduled Searches](/docs/alerts/scheduled-searches/create-real-time-alert).
1 change: 1 addition & 0 deletions cid-redirects.json
Original file line number Diff line number Diff line change
Expand Up @@ -3865,6 +3865,7 @@
"/Dashboards-and-Alerts/Alerts/04-Create-an-Email-Alert": "/docs/alerts/scheduled-searches/create-email-alert",
"/Dashboards-and-Alerts/Alerts/08-Save-to-Index": "/docs/alerts/scheduled-searches/save-to-index",
"/Dashboards-and-Alerts/Alerts/03-Create-a-Real-Time-Alert": "/docs/alerts/scheduled-searches/create-real-time-alert",
"/docs/alerts/scheduled-searches/deprecation": "/docs/alerts/scheduled-searches/create-real-time-alert",
"/Data_Enrichment": "/docs/send-data/data-enrichment",
"/Manage/Connections_and_Integrations/Webhook_Connections": "/docs/alerts/webhook-connections",
"/Manage/Connections_and_Integrations/Webhook_Connections/About_Webhook_Connections": "/docs/alerts/webhook-connections/set-up-webhook-connections",
Expand Down
4 changes: 2 additions & 2 deletions docs/alerts/difference-from-scheduled-searches.md
Original file line number Diff line number Diff line change
Expand Up @@ -16,7 +16,7 @@ Scheduled Searches address two primary use cases:

## Monitors

Monitors are specifically designed for the first use case: alerting. They offer additional capabilities such as auto-resolution and support for multiple notification channels. Any Scheduled Searches created for alerting purposes can be moved to Monitors, including [real-time Scheduled Searches](/docs/alerts/scheduled-searches/create-real-time-alert).
Monitors are specifically designed for the first use case: alerting. They offer additional capabilities such as auto-resolution and support for multiple notification channels. Any Scheduled Searches created for alerting purposes can be moved to Monitors.

## Feature differences

Expand All @@ -31,7 +31,7 @@ Beyond the differences in use cases, there are distinct feature differences betw
| Alert disablement | No | Yes*<br/>(Disable is a manual operation. We do not support scheduled disabling of alerts.) |
| API support | Partial*<br/>(Supported via content sync API) | Yes |
| Terraform support | Yes<br/>(see [content API resource](https://registry.terraform.io/providers/SumoLogic/sumologic/latest/docs/resources/content)) | Yes |
| Log Search operator support | Yes*<br/>(Some operators are not supported for real-time alerts) | Yes |
| Log Search operator support | Yes | Yes |
| Outlier-based alerts | Yes | Yes |
| Access control | Object-Level Access Control | Object-Level Access Control (Per request - limited availability) |
| Audit logs for CRUD and system events (e.g., notifications sent, failures) | Yes | Yes |
Expand Down
11 changes: 0 additions & 11 deletions docs/alerts/scheduled-searches/create-email-alert.md
Original file line number Diff line number Diff line change
Expand Up @@ -80,17 +80,6 @@ Do either of the following:
If you're a new user and someone has forwarded you an alert email, the links to the search will not work until you've completed your setup process.
:::


### Real-time alerts

:::warning Solution Deprecated
Effective May 15, 2024, Real-Time Scheduled Searches have been deprecated and you will no longer be able to create them. Real-Time Scheduled Searches created before that date will continue to function until May 15, 2025. We encourage you instead to [create a monitor](/docs/alerts/monitors/create-monitor) for use cases that require real-time alerting. [Learn more](/docs/alerts/scheduled-searches/deprecation).
:::

[Real-time alerts](create-real-time-alert.md) continuously monitor your Sumo Logic deployment, and return alert emails whenever conditions are met.

Scheduled Searches run according to the time zone of an individual's computer and browser, not according to the time zone of logs.

## Customize your email alert subject and content

You can use variables to customize the subject of your email. You can also select the features you want to include in your email. For details, see [Create a Scheduled Search Email Alert](create-email-alert.md).
Expand Down
74 changes: 25 additions & 49 deletions docs/alerts/scheduled-searches/create-real-time-alert.md
Original file line number Diff line number Diff line change
@@ -1,69 +1,45 @@
---
id: create-real-time-alert
title: Create a Scheduled Search Real-Time Alert
description: Real-time alerts notify you of error conditions right when they occur.
title: Deprecation of Real-Time Scheduled Searches
---

:::warning Solution Deprecated
The ability to create new real-time alert scheduled searches has been deprecated. While you can no longer create new real-time alerts, existing real-time alerts will continue to function as before. [Learn more](/docs/alerts/scheduled-searches/deprecation).
:::warning Deprecated Feature
As of **May 15, 2025**, Real-Time Scheduled Searches are officially deprecated and no longer run in real time. All remaining Real-Time Scheduled Searches have been automatically converted to 15-minute schedules. For real-time alerting, use [Monitors](/docs/alerts/monitors/overview).
:::

Real-time alerts are scheduled searches that run nearly continuously. This means that you're informed in real time when error conditions exist.
As part of our ongoing platform improvements, Sumo Logic has officially deprecated [Real-Time Scheduled Searches](/docs/alerts/scheduled-searches/create-real-time-alert). These legacy searches have been replaced by [Monitors](/docs/alerts/monitors/overview), which offer more powerful, scalable, and flexible alerting capabilities.

When an alert condition is satisfied, Sumo Logic triggers the selected alert type and examines ingested data in a rolling window using the time range you define. When a new result is found, you'll receive an email.

This document describes how to manage existing real-time alert scheduled searches. Although creating new real-time alerts is no longer supported, you can still view, edit, and delete existing ones.
## Deprecation timeline

## When to use
| Date | Change |
|:-----|:-------|
| **May 29, 2024** | Creation of new Real-Time Scheduled Searches was disabled across all Sumo Logic accounts |
| **May 15, 2025** | All remaining Real-Time Scheduled Searches were automatically converted to 15-minute schedules (except for a small number of approved exceptions). An audit log entry was created for each conversion. |

Only use real-time schedules when you know your data is ingested within a few minutes of its creation. The [receipt time](/docs/search/get-started-with-search/build-search/use-receipt-time) should be within a few minutes of your log's [message time](/docs/search/get-started-with-search/search-basics/built-in-metadata). Learn about
troubleshooting timestamp discrepancies [here](/docs/send-data/collector-faq#troubleshooting-time-discrepancies).
Real-Time frequency is no longer supported, and any attempt to edit or recreate a real-time schedule will default to 15-minute intervals.

Real-time alerts are not duplicated, which means that if a specific raw log message has triggered an alert once already, that same log message will not trigger an alert a second time.

For example, if **Message X** caused an alert to be sent at **Time T**, and Sumo Logic detects **Message X** again at **Time T+1**, Sumo Logic does not send a second alert at **Time T+1**. But if Sumo Logic detects **Message Y** at **Time T+1**, a new alert is sent, because the root cause is different.
## Why did this change happen?

:::important
If the time zone of messages is set incorrectly, those logs won't be picked up by real-time alerts.
:::


## Limitations

* The time range of a real-time alerts must be between 5 and 15 minutes. 
* Searching by receipt time is not supported.
* If your search query result is a subset of your previous run's result, a real-time alert will not trigger. It will trigger only when there are new results compared to the previous run.
* A maximum of 120 emails are sent per day from real-time alerts.
* Aggregate real-time scheduled searches evaluate the first 1,000 results per search. For example, if the scheduled search is supposed to return more than 1,000 results, reduce the scope of the search.
* Non-aggregate real-time scheduled searches evaluate the first 100 results per search. For example, if the scheduled search is supposed to return more than 100 results, either convert it to aggregate scheduled search or reduce the scope of the search.
* The [`_dataTier`](/docs/manage/partitions/data-tiers) search modifier is not supported in real-time alert searches.

### Operator limitations
[Monitors](/docs/alerts/monitors/overview) support real-time alerting on both logs and metrics, and offer significant advantages over Scheduled Searches, including:

* Some queries cannot be used in real-time alerts searches. Other operators can be used in real-time search, but in the search, they must be included after the first "group-by" phrase:
* [Multiple trigger conditions](/docs/alerts/monitors/create-monitor/#step-1-set-trigger-conditions) (Critical, Warning, Missing Data)
* [Alert grouping](/docs/alerts/monitors/alert-grouping/)
* [Playbook support](/docs/alerts/monitors/alert-response/#alert-details)
* [AI-driven alerting](/release-notes-service/2024/12/31/#march-12-2024-alerts)
* [Integration with the Alert Response page](/docs/alerts/monitors/alert-response/)

| Not supported for real-time alerts | Must be added after a "group by" phrase |
| :-- | :-- |
| <ul><li>Count_frequent</li><li>Details</li><li>First, Last - instead use the withtime option, see [`most_recent` and `least_recent`](/docs/search/search-query-language/group-aggregate-operators/most-recent-least-recent).</li><li>LogReduce</li><li>Now()</li><li>Outlier will omit the first N (window size) data points in results because those data points are used in the training phase.</li><li>Join</li><li>Parse using</li><li>queryStartTime()</li><li>queryEndTime()</li><li>Save</li><li>Sessionize</li><li>Subquery</li><li>Threat Intel</li><li>Trace</li><li>Timeslice greater than 1 day</li><li>Transactionize</li></ul> | <ul><li>Accum</li><li>Backshift</li><li>Diff</li><li>Join</li><li>Limit</li><li>RollingStd</li><li>Smooth</li><li>Sort</li><li>Top</li><li>Total</li><li>Transaction By Flow</li><li>Compare With can be used when your query's aggregate operation is grouped by a [`timeslice`](/docs/search/search-query-language/search-operators/timeslice).</li></ul> |
Monitors are the strategic focus for our future alerting development and enhancements.

* Real-time queries using [Time Compare](/docs/search/time-compare) need to have at least three timeslices within its time range. For example, if the time range is 10 minutes, your timeslices need to be no longer than 3 minutes so that there are at least three of them.
## What should I do?

## Viewing existing real-time alerts
If you're still relying on Scheduled Searches for real-time alerting, we strongly recommend migrating to Monitors for the most accurate, flexible, and reliable experience.

- Navigate to the **Alerts** section in your Sumo Logic dashboard.
- Use the search functionality to locate existing real-time alerts.

## Editing existing real-time alerts

- Click on the real-time alert you wish to edit.
- Make necessary changes to the alert parameters (such as conditions or notification settings).
- Save your changes to update the alert.

## Deleting existing real-time alerts

- Select the real-time alert you want to delete.
- Click the **Delete** button and confirm the deletion.
:::note Can I import a Scheduled Search into a Monitor?
No. Scheduled Searches and Monitors use different JSON structures. You’ll need to recreate the search logic manually in the [Monitor creation UI](/docs/alerts/monitors/create-monitor/).
:::

## Alternatives to real-time alerts
If your use case doesn't require real-time execution, your automatically converted Scheduled Search will continue to run every 15 minutes. However, it may be a good time to consider consolidating logic in Monitors for long-term maintenance.

Since the creation of new real-time alerts is deprecated, we recommend using monitors to achieve similar functionality.
If you have any questions, please contact your account team or open a [Support ticket](https://support.sumologic.com/support/s/).
36 changes: 0 additions & 36 deletions docs/alerts/scheduled-searches/deprecation.md

This file was deleted.

21 changes: 0 additions & 21 deletions docs/alerts/scheduled-searches/faq.md
Original file line number Diff line number Diff line change
Expand Up @@ -128,27 +128,6 @@ Additional consideration for performance tests:
* If the data you are testing against is not reflective of the actual volume you’ll be scanning on a recurring basis, then the test itself should be considered invalid. Similarly, avoid scheduling searches preemptively. Wait until you get a good sample size and make sure your live streaming is completely set up.
* If there are plans to add more data to your account in the near future, keep that in mind in your testing and include a buffer to make sure that your increased data volume won’t cause your scheduled search to time out.


## How do I set a real-time alert with more than 1,000 results?

Scheduled Search alert condition thresholds are based on the number of rows returned in your search results. It does not consider any values that may be present within a column of those rows.

If your query does not perform any aggregations the Scheduled Search threshold will apply to the number of raw messages returned with a query, as seen under the **Messages** tab of the search. If a query contains an aggregate operation - for example, `count`, `sum`, `min`, `max` - the Scheduled Search threshold will be applied to the number of aggregate rows returned by the query, as seen within the **Aggregate** tab of the results.

When performing an aggregation as part of a query, and wanting to alert when a specific aggregate value meets a threshold, the threshold for that field value will need to be included as part of the query itself. This can typically be done by providing a [`where`](/docs/search/search-query-language/search-operators/where) condition after the aggregation within the query. For example:

```sql
_sourceCategory=aws/prod
| json "message","logStream","logGroup"
| parse field=message "* * * * * * * * * * * * * *" as version,accountID,interfaceID,src_ip,dest_ip,src_port,dest_port,Protocol,Packets,bytes,StartSample,EndSample,Action,status
| timeslice 1m
| where action="REJECT"
| count as drops by _timeslice
| where drops > 1000
```

This will ensure results are only returned when the field value meets the threshold provided within the query. The threshold set within the Scheduled Search would then be set to alert based on the resulting number of rows that met the threshold set within the query. For example: `Greater than\> 0`


## Why have I received a "Scheduled Search Email Quota Reached" notification?

Expand Down
Loading