})
Edit or Cancel a Scheduled Search
diff --git a/docs/alerts/scheduled-searches/schedule-search.md b/docs/alerts/scheduled-searches/schedule-search.md
index 5422491d04..d56352b179 100644
--- a/docs/alerts/scheduled-searches/schedule-search.md
+++ b/docs/alerts/scheduled-searches/schedule-search.md
@@ -74,7 +74,7 @@ Under **Send Notification**, select the condition for when you want an alert to
* **Every time a search is complete**. Select this option if you want an email with search results every time the search is run (depending on the frequency, you could get an email every 15 minutes, every hour, or once a day).
* **If the following condition is met**. Select this option if you'd like to set up a Scheduled Search that alerts you to specific events.
- * **Number of results.** Depending on the search, set a condition to receive an email by the number of results. If your saved search returns log messages, then the alert will use the number of messages you specify. If your query produces aggregate results, the alert will use the number of rows or aggregates (or groups) and will not trigger on the number of raw results. For more control of your query, you can build in a threshold (for example `| where _count\> 30`) into the Search itself and set the alerts condition here to Greater than 0. That way the query will generate results if the expected condition is met. See this [FAQ](/docs/alerts/scheduled-searches/faq/#how-do-i-set-a-real-time-alert-with-more-than-1000-results) for an example.
+ * **Number of results.** Depending on the search, set a condition to receive an email by the number of results. If your saved search returns log messages, then the alert will use the number of messages you specify. If your query produces aggregate results, the alert will use the number of rows or aggregates (or groups) and will not trigger on the number of raw results. For more control of your query, you can build in a threshold (for example `| where _count\> 30`) into the Search itself and set the alerts condition here to Greater than 0. That way the query will generate results if the expected condition is met.
* **Equal to.** Choose if there is an exact number of records in a search result at which you want to be notified.
* **Greater than.** Choose if you want to be notified only if the search results include greater than the number of messages or groups you set in the text box.
* **Greater than or equal to.** Choose if you want to be notified only if the search results include greater than or equal to that number of messages or groups you set in the text box. For example, to ensure you're notified only when the specific query conditions are met, set the **Number of results** condition to greater than 0.
diff --git a/docs/alerts/webhook-connections/schedule-searches-webhook-connections.md b/docs/alerts/webhook-connections/schedule-searches-webhook-connections.md
index 9b903a4905..4bc05369ad 100644
--- a/docs/alerts/webhook-connections/schedule-searches-webhook-connections.md
+++ b/docs/alerts/webhook-connections/schedule-searches-webhook-connections.md
@@ -31,8 +31,7 @@ To set up a scheduled search for a Webhook Connection:
1. Select a **Webhook** from the **Connection** list.
* (Optional) Select the checkbox if you want a **separate alert sent for each search result**. You can set up to a maximum of 100 alerts. Any results that exceed the configured maximum do not generate an alert. For example, if your scheduled search is configured to send a maximum of 50 alerts and generates 60 results only the first 50 results will generate an alert, all subsequent results will not generate an alert.
:::note
- - This may generate duplicate alerts for non-real-time schedules. If your search time range is longer than the search frequency (like a window of 60 minutes, but the frequency of 15 minutes) duplicate alerts are sent since there is an overlap of 45 minutes between each search and all results are sent, not just the difference.
- - If the alert condition is: Number of results equal to 0 and "Send a separate alert for each search result" checkbox is selected, it would not trigger any alerts when the alert threshold matches since there are no results to itemize.
+ If the alert condition is: Number of results equal to 0 and "Send a separate alert for each search result" checkbox is selected, it would not trigger any alerts when the alert threshold matches since there are no results to itemize.
:::
* [Webhook payload variables](set-up-webhook-connections.md) will have values generated for each result. For example, a payload defined as:
```
diff --git a/docs/contributing/glossary.md b/docs/contributing/glossary.md
index addd5a71ad..d8620d2025 100644
--- a/docs/contributing/glossary.md
+++ b/docs/contributing/glossary.md
@@ -24,7 +24,7 @@ We also maintain a [DevOps and Security Glossary](https://www.sumologic.com/glos
**[Aggregate](/docs/search/search-query-language/group-aggregate-operators)**. A group of data returned by a search, displayed in a simple table in the Aggregates tab of the Search page.
-**[Alert](/docs/alerts)**. A notification you can configure for a scheduled search. There are multiple alert types: Email, Script Action, ServiceNow Connection, Webhook, Save to Index, and Real Time Alerts.
+**[Alert](/docs/alerts)**. A notification you can configure for a scheduled search. There are multiple alert types, such as Email, Script Action, ServiceNow Connection, Webhook, and Save to Index.
**[Allowlist](/docs/manage/security/create-allowlist-ip-cidr-addresses)**. Sumo Logic’s Service Allowlist Settings allow you to explicitly grant access to specific IP addresses and/or CIDR notations for logins, APIs, and dashboard access.
diff --git a/docs/contributing/word-list.md b/docs/contributing/word-list.md
index 59af3dbf42..b7b60a6635 100644
--- a/docs/contributing/word-list.md
+++ b/docs/contributing/word-list.md
@@ -149,8 +149,6 @@ If we are not clear on its usage, the term shouldn’t be used at all: Don't use
## R
-**Real Time**. As in Real Time alerts. Use two words, no hyphen. Should always be capitalized when referring to Real Time alerts, as that is a feature name. Not capitalized for a general use, as in "real time analysis".
-
**Repo**. Short for repository. No need to spell out repository as our audience is technical enough for this to be clear.
diff --git a/docs/dashboards/share-dashboard-outside-org.md b/docs/dashboards/share-dashboard-outside-org.md
index 4b71b0b8a7..826988101f 100644
--- a/docs/dashboards/share-dashboard-outside-org.md
+++ b/docs/dashboards/share-dashboard-outside-org.md
@@ -89,13 +89,6 @@ When someone views a dashboard without signing in, Sumo Logic logs the following
You can use [Scheduled Searches](/docs/alerts/scheduled-searches) to create alerts and reports on sharing dashboards outside your organization.
-```sql title="Real-time alert when a user shares a dashboard"
-_index=sumologic_audit and _sourceName=REPORT "Published REPORT"
-| parse "Published REPORT Name=*, UserName=* UserEmail=*} PublisherName=* PublisherEmail=*} Visibility=* URL=*" as dashboardName,userName,userEmail,publisherName,publisherEmail,visibility, URL
-| count by dashboardName, userName, userEmail, visibility, URL
-| fields -_count
-```
-
```sql title="Scheduled search report of dashboard views"
_index=sumologic_audit and _sourceName=REPORT "Viewed Report"
| parse "Name=*, Id=Some(*)," as dashboardName,dashboardId
diff --git a/docs/get-started/account-settings-preferences.md b/docs/get-started/account-settings-preferences.md
index e078ac7eb8..80f135d22f 100644
--- a/docs/get-started/account-settings-preferences.md
+++ b/docs/get-started/account-settings-preferences.md
@@ -78,7 +78,7 @@ These settings apply only to your personal account and do not affect other users
If you want the Sumo Logic user interface to use your local time zone, or a time zone different from the time zone used in the timestamp of your log messages, change the setting here. This is a personal setting, and does not change the time zone for anyone else in your organization.
-This option overrides the timezone set in your web browser, and affects all hours and minutes displayed in the user interface, including time ranges on the Search page, the Time column in the Messages pane, and in Dashboards. It does not affect the configurations of previously created Scheduled Searches or Real Time Alerts. For more information, see [Timestamps, Time Zones, Time Ranges, and Date Formats](/docs/send-data/reference-information/time-reference).
+This option overrides the timezone set in your web browser, and affects all hours and minutes displayed in the user interface, including time ranges on the Search page, the Time column in the Messages pane, and in Dashboards. It does not affect the configurations of previously created Scheduled Searches. For more information, see [Timestamps, Time Zones, Time Ranges, and Date Formats](/docs/send-data/reference-information/time-reference).
#### Always show the timezone offset in displayed timestamps
diff --git a/docs/manage/manage-subscription/cloud-flex-legacy-accounts.md b/docs/manage/manage-subscription/cloud-flex-legacy-accounts.md
index 1ab708f5fe..b512ac6336 100644
--- a/docs/manage/manage-subscription/cloud-flex-legacy-accounts.md
+++ b/docs/manage/manage-subscription/cloud-flex-legacy-accounts.md
@@ -47,7 +47,6 @@ The following table provides a summary list of key features by package accounts.
| Metrics data retention | |  |  |  |
| Metrics data retention | |  |  |  |
| [Partitions](/docs/manage/partitions) | |  |  |  |
-| Real Time Alerts | |  |  |  |
| SAML | |  |  |  |
| Scheduled Views | |  |  |  |
| Search Job API | |  |  |  |
@@ -125,7 +124,7 @@ The top panel of the Account Overview page provides an at-a-glance view of your
* **Frequent Ingest**. Shows your daily capacity for log ingest to the Frequent Data Tier, and your average daily usage. If the daily ingest average over the billing cycle is above your capacity, you will be charged the on-demand rate for the difference.
* **Metrics Ingest**. Shows your daily capacity for metrics ingest, and your average daily usage, both in DPM. If the daily ingest average over the billing cycle is above your capacity, you will be charged the on-demand rate for the difference. If your daily usage average is higher than your capacity, you will be charged the on-demand rate for the difference.
* **Storage.** Shows your daily storage capacity and average daily storage usage. You can adjust capacity use by modifying your [retention periods](../partitions/manage-indexes-variable-retention.md).
-* **Auto Refresh Dashboard Panels and Real Time Alerts.** Show the number of auto refresh dashboard panels and real time alerts you have set up. Compares the number allowed to the number already in use. For example, out of 200, 174 have been used.
+* **Auto Refresh Dashboard Panels.** Show the number of auto refresh dashboard panels you have set up. Compares the number allowed to the number already in use. For example, out of 200, 174 have been used.
To view the Account page, do the following:
diff --git a/docs/manage/manage-subscription/sumo-logic-credits-accounts.md b/docs/manage/manage-subscription/sumo-logic-credits-accounts.md
index f1d9d8ccf3..c37363d3de 100644
--- a/docs/manage/manage-subscription/sumo-logic-credits-accounts.md
+++ b/docs/manage/manage-subscription/sumo-logic-credits-accounts.md
@@ -105,7 +105,6 @@ The following table provides a summary list of key features by Credits package a
| Monitors |  |  |  |  |  |  |
| Partitions |  |  |  |  |  |  |
| PCI Compliance App | |  | |  |  |  |
-| Real Time Alerts |  |  |  |  |  |  |
| Real User Monitoring (RUM) | |  |  |  |  |  |
| Root Cause Explorer | | | |  | |  |
| SAML |  |  |  |  |  |  |
diff --git a/docs/manage/manage-subscription/sumo-logic-flex-accounts.md b/docs/manage/manage-subscription/sumo-logic-flex-accounts.md
index d83d89d04b..e3aca6715f 100644
--- a/docs/manage/manage-subscription/sumo-logic-flex-accounts.md
+++ b/docs/manage/manage-subscription/sumo-logic-flex-accounts.md
@@ -127,7 +127,6 @@ The following table provides a summary list of key features by Flex package acco
| Playbooks (including complete Sumo Logic playbook catalog) | | | |  |
| Predictive Analytics and Outlier Detection |  |  | |  |
| Progressive Automation | | | |  |
-| Real Time Alerts |  |  |  | |
| Real User Monitoring (RUM) | |  |  | |
| Reliability Management (SLIs/SLOs) | | | | |
| Risk Assessment | |  | | |
diff --git a/docs/manage/partitions/data-tiers/searching-data-tiers.md b/docs/manage/partitions/data-tiers/searching-data-tiers.md
index db655a10fb..7a0bdb15da 100644
--- a/docs/manage/partitions/data-tiers/searching-data-tiers.md
+++ b/docs/manage/partitions/data-tiers/searching-data-tiers.md
@@ -73,7 +73,6 @@ The `_dataTier` search modifier is not supported in:
* Live mode dashboards
* Role search filters
-* Real time alerts
* Partition routing expressions
* Logs-to-Metrics rules
* In scheduled searches, setting `_dataTier` to All, Frequent, or Infrequent is not supported.
diff --git a/docs/search/behavior-insights/logexplain.md b/docs/search/behavior-insights/logexplain.md
index 6a8fd49cee..302d657173 100644
--- a/docs/search/behavior-insights/logexplain.md
+++ b/docs/search/behavior-insights/logexplain.md
@@ -53,7 +53,6 @@ With the provided results you can:
* Field values must be categorical.
* [Built-in metadata fields](/docs/search/get-started-with-search/search-basics/built-in-metadata) are not supported.
-* Not supported with [Real Time alerts](../../alerts/scheduled-searches/create-real-time-alert.md).
* [Time Compare](/docs/search/time-compare) and the [`compare` operator](/docs/search/search-query-language/search-operators/compare) are not supported against LogExplain results.
* Response fields `_explanation`, `_relevance`, `_test_coverage`, and `_control_coverage` are not supported with [Dashboard filters](/docs/dashboards/filter-template-variables).
* If you reach the memory limit you can try to shorten the time range or the number of specified fields. When the memory limit is reached you will get partial results on a subset of your data.
diff --git a/docs/search/search-cheat-sheets/log-operators.md b/docs/search/search-cheat-sheets/log-operators.md
index cac8a2db1e..c9882ca685 100644
--- a/docs/search/search-cheat-sheets/log-operators.md
+++ b/docs/search/search-cheat-sheets/log-operators.md
@@ -392,7 +392,7 @@ This section provides detailed syntax, rules, and examples for Sumo Logic Opera
logexplain |
The logexplain operator allows you to compare sets of structured logs based on events you're interested in. Structured logs can be in JSON, CSV, key-value, or any structured format. |
_explanation
_relevance
_test_coverage
_control_coverage |
-
Not supported with Real Time alerts.
Time Compare and the compare operator are not supported against LogExplain results. |
+
Time Compare and the compare operator are not supported against LogExplain results. |
_sourceCategory=stream
| if(_raw matches "error", 1, 0) as hasError
| logexplain hasError == 1 on _sourceHost |
@@ -413,7 +413,7 @@ This section provides detailed syntax, rules, and examples for Sumo Logic Opera
| logreduce values |
The logreduce values operator allows you to quickly explore structured logs by known keys. Structured logs can be in JSON, CSV, key-value, or any structured format. |
_cluster_id
_signature
_count |
- Not supported with Real Time alerts. |
+ |
_sourceCategory= *cloudtrail* errorCode
| json field=_raw "eventSource" as eventSource
| json field=_raw "eventName" as eventName
| json field=_raw "errorCode" as errorCode
| logreduce values on eventSource, eventName, errorCode |
diff --git a/docs/search/search-query-language/search-operators/join.md b/docs/search/search-query-language/search-operators/join.md
index 4dd441cdaf..5ba2b4d3dc 100644
--- a/docs/search/search-query-language/search-operators/join.md
+++ b/docs/search/search-query-language/search-operators/join.md
@@ -56,7 +56,6 @@ on t1.a = t2.c
`The number of output messages exceeds 10,000,000. Please refine your search or shorten the time range to reduce the number of output messages.`
* Only conjunctive conditions (AND) are allowed. Using NOT or OR conditions is not supported.
-* [Real Time Alerts](/docs/alerts/scheduled-searches/create-real-time-alert.md) do not support the join operator.
* The join operator uses sliding windows to store candidates for joins in order to prevent unbounded memory usage when joining between two large relations. Because of this, the result of the join could be incomplete and inconsistent from run-to-run.
* The following conditions are not currently supported in the ON clause:
diff --git a/docs/search/search-query-language/search-operators/queryendtime.md b/docs/search/search-query-language/search-operators/queryendtime.md
index a7f64b5366..87fa211399 100644
--- a/docs/search/search-query-language/search-operators/queryendtime.md
+++ b/docs/search/search-query-language/search-operators/queryendtime.md
@@ -7,7 +7,7 @@ sidebar_label: queryEndTime()
The `queryEndTime()` operator returns the end time of the search [time range](/docs/search/get-started-with-search/build-search/set-time-range) in milliseconds. You can use it in combination with [`queryStartTime()`](querystarttime.md) to establish times and ranges for your non-continuous queries.
:::note
-For dashboards in live mode or real time scheduled searches `queryTimeRange()` is a more suitable option. In most cases the results would still be the same as using `queryStartTime()` and `queryEndTime()`, but the latter can be off from the real range by a few milliseconds.
+For dashboards in live mode, `queryTimeRange()` is a more suitable option. In most cases, the results would still be the same as using `queryStartTime()` and `queryEndTime()`, but the latter can be off from the real range by a few milliseconds.
:::
## Syntax
diff --git a/docs/search/search-query-language/search-operators/querystarttime.md b/docs/search/search-query-language/search-operators/querystarttime.md
index 9be501655e..3303a547af 100644
--- a/docs/search/search-query-language/search-operators/querystarttime.md
+++ b/docs/search/search-query-language/search-operators/querystarttime.md
@@ -7,7 +7,7 @@ sidebar_label: queryStartTime()
The `queryStartTime()` operator returns the start time of the search [time range](/docs/search/get-started-with-search/build-search/set-time-range) in milliseconds. You can use it in combination with [`queryEndTime()`](queryendtime.md) to establish times and ranges for your non-continuous queries.
:::note
-For dashboards in live mode or real time scheduled searches, `queryTimeRange()` is a more suitable option. In most cases the results would still be the same as using `queryStartTime()` and `queryEndTime()`, but the latter can be off from the real range by a few milliseconds.
+For dashboards in live mode, `queryTimeRange()` is a more suitable option. In most cases, the results would still be the same as using `queryStartTime()` and `queryEndTime()`, but the latter can be off from the real range by a few milliseconds.
:::
## Syntax
diff --git a/docs/search/search-query-language/search-operators/querytimerange.md b/docs/search/search-query-language/search-operators/querytimerange.md
index d4129160d7..4425073d9e 100644
--- a/docs/search/search-query-language/search-operators/querytimerange.md
+++ b/docs/search/search-query-language/search-operators/querytimerange.md
@@ -4,7 +4,7 @@ title: queryTimeRange Search Operator
sidebar_label: queryTimeRange()
---
-The `queryTimeRange()` operator returns the time duration for the query being executed in milliseconds. You can use it to establish time ranges for your continuous queries (CQs). This is a preferred operator for queries that run in auto refresh dashboards or real time scheduled searches since it is more accurate than [`queryStartTime()`](querystarttime.md) and [`queryEndTime()`](queryendtime.md) operators in these cases.
+The `queryTimeRange()` operator returns the time duration for the query being executed in milliseconds. You can use it to establish time ranges for your continuous queries (CQs). This is a preferred operator for queries that run in auto refresh dashboards since it is more accurate than [`queryStartTime()`](querystarttime.md) and [`queryEndTime()`](queryendtime.md) operators in these cases.
## Syntax
diff --git a/docs/search/search-query-language/transaction-analytics/transactionize-operator.md b/docs/search/search-query-language/transaction-analytics/transactionize-operator.md
index 9725ca094a..afc4f4b448 100644
--- a/docs/search/search-query-language/transaction-analytics/transactionize-operator.md
+++ b/docs/search/search-query-language/transaction-analytics/transactionize-operator.md
@@ -59,9 +59,7 @@ Syntax section. For example,
To address this situation, try one or more of these options:
* Reduce the [time range](/docs/search/get-started-with-search/build-search/set-time-range) of your search to reduce the scope.
* Reduce the scope of your search by using parameters (such as `maxlogs`, `maxspan`, or `endswith`) that are listed above in the [Parameters](#parameters) section.
- * Run a second `transactionize` operator immediately after your first one. This will take the potentially ungrouped messages of your first `transactionize` search and group them correctly.
-
-* Transactionize is not supported in [Real Time scheduled searches](../../../alerts/scheduled-searches/create-real-time-alert.md).
+ * Run a second `transactionize` operator immediately after your first one. This will take the potentially ungrouped messages of your first `transactionize` search and group them correctly.
## Example
diff --git a/docs/search/subqueries.md b/docs/search/subqueries.md
index 32fb637ab8..cf16ce4b58 100644
--- a/docs/search/subqueries.md
+++ b/docs/search/subqueries.md
@@ -15,7 +15,7 @@ In a subquery, the parent query contains the main body of the query while the c
* **Parent query**. Depends on the input from a child query or queries to finish its execution.
:::note Limitations
-Subqueries are not supported in auto refresh dashboards, real-time Scheduled Searches, Field Extraction Rules, and Scheduled Views.
+Subqueries are not supported in auto refresh dashboards, Field Extraction Rules, and Scheduled Views.
:::
## Syntax
@@ -148,7 +148,6 @@ The results only contain the values from the key-value pairs, the keys (field n
* In Scheduled Views
* Inside FERs
* Auto Refresh Dashboards
- * Real Time Scheduled Searches
## Example subquery
diff --git a/docs/send-data/reference-information/time-reference.md b/docs/send-data/reference-information/time-reference.md
index f77deb04db..82fe7a0b58 100644
--- a/docs/send-data/reference-information/time-reference.md
+++ b/docs/send-data/reference-information/time-reference.md
@@ -273,7 +273,7 @@ They will see the same data, just displayed using their custom set time zone. Fo
The **Time Range** field on the **Search** page uses the time zone that is set for the Sumo Logic user interface. This is either the default time zone used in the web browser and set by the operating system, or the **Default Timezone** setting on the **Preferences** page, if you have set this option.
-When you create a [Scheduled Search](/docs/alerts/scheduled-searches) or a [real-time alert](/docs/alerts/scheduled-searches/create-real-time-alert), the time range of the search that you save uses the time zone that is set for the Sumo Logic user interface. If you have changed the time zone using the **Default Timezone** setting, this time zone will be used for your Scheduled Searches and Real Time Alerts.
+When you create a [Scheduled Search](/docs/alerts/scheduled-searches), the time range of the search that you save uses the time zone that is set for the Sumo Logic user interface. If you have changed the time zone using the **Default Timezone** setting, this time zone will be used for your Scheduled Searches.
:::note
The **Default Timezone** setting does not automatically update the configurations of existing Scheduled Searches or real-time alerts. If you'd like your Scheduled Searches and real-time alerts to use the same time zone as your user interface, you'll need to edit them to do so, and save them.
diff --git a/i18n/ja/alerts/alerts/scheduled-searches/create-real-time-alert.md b/i18n/ja/alerts/alerts/scheduled-searches/create-real-time-alert.md
deleted file mode 100644
index aea1a954db..0000000000
--- a/i18n/ja/alerts/alerts/scheduled-searches/create-real-time-alert.md
+++ /dev/null
@@ -1,64 +0,0 @@
----
-id: create-real-time-alert
-title: Create a Real-Time Alert
-sidebar_label: Create a Real-Time Alert
-description: Set up real-time alerts to learn of error conditions right when they occur.
----
-
-Real-time alerts are scheduled searches that run nearly continuously. That means that you're informed in real time when error conditions exist.
-
-When an alert condition is satisfied Sumo Logic triggers the selected alert type. Sumo Logic examines ingested data in a rolling window using the Time Range you define. Any time a new result is found, another email is sent.
-
-:::note
-Only use real time schedules when you know your data is ingested within a few minutes of its creation. The [receipt time](../../search/get-started-with-search/build-search/use-receipt-time.md) should be within a few minutes of your log's [message time](/docs/search/get-started-with-search/search-basics/built-in-metadata). See how to [troubleshoot timestamp discrepancies](/docs/send-data/collector-faq#troubleshooting-time-discrepancies).
-:::
-
-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.
-
-:::important
-If the time zone of messages is set incorrectly, those logs won't be picked up by real-time alerts.
-:::
-
-## General limitations
-
-* The time range of a real-time alert must be between 5 and 15 minutes.
-* Searching by receipt time is not supported.
-* A maximum of 120 emails are sent per day per real-time alert.
-* 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.
-
-### Notification results
-
-The results from your search will vary based on the type of alert selected. The following table shows the differences, the above limitations still apply to this logic:
-
-| Alert type | Results in notification |
-| -- | -- |
-| [Webhook](/docs/alerts/webhook-connections/schedule-searches-webhook-connections) | If the **Send a separate alert for each search result checkbox** is selected (in step 6) only new results from subsequent searches are sent in the alert payload. Otherwise, all results are sent. |
-| [Save to Index](save-to-index.md) | All results are saved from an **aggregate** query.
Only new results from subsequent searches are saved from a **non-aggregate** query. |
-| [Save to Lookup](save-to-lookup.md) | All results are saved. |
-
-## Operator limitations
-
-1. Some queries can not be used in real-time alert searches. Other operators can be used in real-time search, but in the search, they must be included after the first "group-by" phrase:
-
-| Not supported for real-time alerts | Must be added after a "group by" phrase |
-| -- | -- |
-| - Count_frequent
- Details
- 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) .
- LogReduce
- Now()
- Outlier will omit the first N (window size) data points in results because those data points are used in the training phase.
- Join
- Parse using
- queryStartTime()
- queryEndTime()
- Save
- Sessionize
- Subquery
- Threat Intel
- Trace
- Timeslice greater than 1 day
- Transactionize
| - Accum
- Backshift
- Diff
- Join
- Limit
- RollingStd
- Smooth
- Sort
- Top
- Total
- Transaction By Flow
- Compare With can be used when your query's aggregate operation is grouped by a [timeslice](../../search/search-query-language/search-operators/timeslice.md). See number 2, below, for details.
|
-
-1. Real time queries using [**time compare**](../../search/time-compare.md) 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.
-
-## Configure a real-time alert
-
-To set up a real-time alert:
-
-1. [Save a search](/docs/search/get-started-with-search/search-basics/save-search).
-1. Click **Schedule this search**.
-
- 
-
-1. **Run Frequency**. Select **Real Time**.
-1. For all other configuration options, see [Schedule a Search](schedule-search.md).
-1. Click **Save**.
diff --git a/i18n/ja/alerts/alerts/scheduled-searches/faqs/real-time-alert-with-greater-than-results.md b/i18n/ja/alerts/alerts/scheduled-searches/faqs/real-time-alert-with-greater-than-results.md
deleted file mode 100644
index 96798cb7bf..0000000000
--- a/i18n/ja/alerts/alerts/scheduled-searches/faqs/real-time-alert-with-greater-than-results.md
+++ /dev/null
@@ -1,23 +0,0 @@
----
-id: real-time-alert-with-greater-than-results
----
-
-# Real Time Alert with greater 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, etc... 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`
-
-
diff --git a/i18n/ja/alerts/alerts/scheduled-searches/index.md b/i18n/ja/alerts/alerts/scheduled-searches/index.md
index 1fb999def1..c726310bd0 100644
--- a/i18n/ja/alerts/alerts/scheduled-searches/index.md
+++ b/i18n/ja/alerts/alerts/scheduled-searches/index.md
@@ -80,14 +80,6 @@ When you create a Scheduled Search, you can save the results to a [Lookup Table]
For instructions, see [Save to Lookup](save-to-lookup.md).
-### Real Time Alerts
-
-Real Time Alerts are scheduled searches that run nearly continuously. That means that you're informed in real time when error conditions exist.
-
-When an alert condition is satisfied, Sumo Logic sends an email (or triggers a script action). Sumo Logic examines ingested data in a rolling window using the Time Range you define. Any time a new result is found, another email is sent.
-
-For instructions, see [Create a Alert](create-real-time-alert.md).
-
### Cloud SIEM Signal
You can trigger the creation of a Cloud SIEM Signal with a scheduled search. Signals are otherwise generated when the conditions of a Cloud SIEM rule are satisfied by a Record. Signals are correlated with other Signals to create a [Cloud SIEM Insight](/docs/cse/get-started-with-cloud-siem/insight-generation-process/).
diff --git a/i18n/ja/alerts/alerts/scheduled-searches/receive-email-alerts.md b/i18n/ja/alerts/alerts/scheduled-searches/receive-email-alerts.md
index e0896fdd87..6b83dee14e 100644
--- a/i18n/ja/alerts/alerts/scheduled-searches/receive-email-alerts.md
+++ b/i18n/ja/alerts/alerts/scheduled-searches/receive-email-alerts.md
@@ -19,8 +19,6 @@ There are three ways to receive the results of scheduled searches in email:
You can be very specific with the alert condition—you can even set an exact number of results that triggers the email. Results can either be the number of log messages *OR* the number of aggregates returned by the saved search. If your saved search returns log messages, then the alert will use the number of messages you specify. If your query produces aggregate results, the alert will use the number of aggregates (or groups).
-* **Real Time Alerts.** (Not available to Sumo Logic Free accounts.) Real Time Alerts continuously monitor your Sumo Logic deployment, and return alert emails whenever conditions are met. You can learn more in [Create a Real Time Alert](create-real-time-alert.md).
-
:::important
Scheduled searches are run according to the time zone of an individual's computer and browser, not according to the time zone of logs.
:::
diff --git a/i18n/ja/alerts/alerts/scheduled-searches/schedule-search.md b/i18n/ja/alerts/alerts/scheduled-searches/schedule-search.md
index 0fc60448b6..e2b7e872ee 100644
--- a/i18n/ja/alerts/alerts/scheduled-searches/schedule-search.md
+++ b/i18n/ja/alerts/alerts/scheduled-searches/schedule-search.md
@@ -26,7 +26,7 @@ You can create a scheduled search at the time you create a search, or edit a s
:::note
- Scheduling a **run frequency** that matches your **time range** will reduce overlapping of searches and duplicate alerts. When you have a search scheduled to run over the same results as a previously scheduled search you would trigger an alert on the same data. This does not apply to [Real Time Alerts](create-real-time-alert.md), they do not duplicate alerts automatically.
+ Scheduling a **run frequency** that matches your **time range** will reduce overlapping of searches and duplicate alerts. When you have a search scheduled to run over the same results as a previously scheduled search you would trigger an alert on the same data.
:::
**Run Frequency**. Determine how frequently your search should run and the time it should start.
@@ -42,7 +42,6 @@ You can create a scheduled search at the time you create a search, or edit a s
* **Daily.** You may also select that your search runs every **Day**, every **Weekday (Mon-Fri)** or **Weekend (Sat-Sun)** and the time. A Daily search will cover exactly 24 hours of activity. You can change the schedule whenever you'd like. Be aware that a scheduled search will run according to the time zone set on your computer at the time you configure the search. For example, if you are in San Francisco and set a search to run at 7:00 AM, it will run at 7:00 AM PST. If you then fly to New York, and your computer resets to EST, when you schedule a new search at 7:00 AM, it will run at 7:00 AM EST. These two searches will run at different times.
* **Every 2, 4, 6, 8, or 12 Hours.** The search will run for the first time at the top of the hour you choose. * **Hourly.** The search will run every hour. We guarantee that hourly searches run every hour but not exactly at :00.
* **Every 15 minutes**. The search will run every 15 minutes, but not exactly at :00, :15, :30, and :45.
- * **Real Time.** Use this option to set up a [Real Time Alert](create-real-time-alert.md). Receipt time is not supported with a Real Time frequency.
* **Never.** Choose this option to temporarily **turn off a scheduled search**.
1. **Time range for scheduled search**. Indicates the time range your query will use to execute, which impacts the results generated by the query. Select the **Last 24 Hours**, to get a daily alert. Otherwise, select the time range you want the scheduled search to be run on. [Absolute time range](../../search/get-started-with-search/search-basics/time-range-expressions.md); for example, 06/10/2020 1:00:00 PM to 06/10/2020 2:00:00 PM is not allowed in Scheduled Searches and presents the message like this: `Invalid query. Static time range is not allowed for scheduled searches. `
@@ -74,7 +73,7 @@ Consider adding an offset to your time range to ensure that all recent events ar
* **Every time a search is complete.** Select this option if you want an email with search results every time the search is run (depending on the frequency, you could get an email every 15 minutes, every hour, or once a day).
* **If the following condition is met**. Select this option if you'd like to set up a scheduled search that alerts you to specific events.
- * **Number of results.** Depending on the search, set a condition to receive an email by the number of results. If your saved search returns log messages, then the alert will use the number of messages you specify. If your query produces aggregate results, the alert will use the number of rows or aggregates (or groups) and will not trigger on the number of raw results. For more control of your query, you can build in a threshold (for example `| where _count\> 30`) into the Search itself and set the alerts condition here to Greater than 0. That way the query will generate results if the expected condition is met. See this [FAQ](/docs/alerts/scheduled-searches/faq#real-time-alert-with-greater-than-1000-results) for an example.
+ * **Number of results.** Depending on the search, set a condition to receive an email by the number of results. If your saved search returns log messages, then the alert will use the number of messages you specify. If your query produces aggregate results, the alert will use the number of rows or aggregates (or groups) and will not trigger on the number of raw results. For more control of your query, you can build in a threshold (for example `| where _count\> 30`) into the Search itself and set the alerts condition here to Greater than 0. That way the query will generate results if the expected condition is met.
* **Equal to.** Choose if there is an exact number of records in a search result at which you want to be notified.
* **Greater than.** Choose if you want to be notified only if the search results include greater than the number of messages or groups you set in the text box.
diff --git a/sidebars.ts b/sidebars.ts
index f4399a1895..277c8c48ee 100644
--- a/sidebars.ts
+++ b/sidebars.ts
@@ -1165,7 +1165,6 @@ module.exports = {
items: [
'alerts/scheduled-searches/schedule-search',
'alerts/scheduled-searches/create-email-alert',
- 'alerts/scheduled-searches/create-real-time-alert',
'alerts/scheduled-searches/edit-cancel',
'alerts/scheduled-searches/save-to-index',
'alerts/scheduled-searches/save-to-lookup',
})
\ No newline at end of file
+We're excited to include the **Index** field as metadata at the bottom of every message row, along with other metadata. This allows you to modify the search query by clicking the index name or view surrounding messages by clicking on the dropdown. [Learn more](/docs/search/get-started-with-search/search-basics/built-in-metadata).