sfanahata · Oct 8, 2026 · Oct 8, 2026 · Oct 8, 2026 · Oct 9, 2026 · Oct 9, 2026
diff --git a/develop-docs/application-architecture/dynamic-sampling/the-big-picture.mdx b/develop-docs/application-architecture/dynamic-sampling/the-big-picture.mdx
@@ -92,7 +92,7 @@ For more granular queries, **stored events are needed**. _The purpose of dynamic
 
 If Sentry applies a 1% dynamic sample rate, you can still receive accurate events per minute (SPM or TPM, depending on event type) and web vital quantiles through total event data backed by metrics. There is also a listing of each of these numbers by the transaction.
 
-When you go into Trace Explorer or Errors, you might want to now split the data by a custom tag you’ve added to your events. This granularity is not offered by metrics, so **these queries need to use stored events**.
+When you go into Explore → Traces or Errors, you might want to now split the data by a custom tag you’ve added to your events. This granularity is not offered by metrics, so **these queries need to use stored events**.
 
 </Alert>
 

diff --git a/develop-docs/sdk/telemetry/traces/index.mdx b/develop-docs/sdk/telemetry/traces/index.mdx
@@ -161,7 +161,7 @@ In memory, spans build up a conceptual tree of timed operations. We call the who
 
 Over the wire, transactions are serialized to JSON as an augmented `Event`, and sent as envelopes. The different envelope types are for optimizing ingestion (so we can route "transaction events" differently than other events, mostly "error events").
 
-In the Sentry UI, you can use Errors and Trace Explorer to look at error and performance events, and the Issues section to dive into grouped errors. The [user-facing tracing documentation](https://docs.sentry.io/concepts/key-terms/tracing/distributed-tracing/) explains more of the concepts on the product level.
+In the Sentry UI, you can use Errors and Explore → Traces to look at error and performance events, and the Issues section to dive into grouped errors. The [user-facing tracing documentation](https://docs.sentry.io/concepts/key-terms/tracing/distributed-tracing/) explains more of the concepts on the product level.
 
 The [Span](/sdk/foundations/transport/event-payloads/span/) class stores each individual span in a
 trace.

diff --git a/docs/concepts/key-terms/enrich-data/index.mdx b/docs/concepts/key-terms/enrich-data/index.mdx
@@ -60,11 +60,11 @@ Learn more in [Search](/concepts/search/).
 
 ### Explore
 
-Explore is a powerful query engine that builds upon your data, allowing you to reveal patterns, anomalies, and deeper insights in the health of your entire system. With this in mind, the more (custom) data you bring into Sentry, the more flexibility you'll gain in building queries that address your environments, releases, custom development, and business characteristics. Sentry supports telemetry data from a wide range of sources, like [errors](/product/errors/), [traces and spans](/product/trace-explorer/), [logs](/product/logs/), [session replays](/product/session-replay/web/), and [application metrics](/product/metrics/).
+[Explore](/product/explore/) queries your telemetry, including [errors](/product/errors/), [traces and spans](/product/trace-explorer/), [logs](/product/logs/), [session replays](/product/session-replay/web/), and [application metrics](/product/metrics/). The more custom data you send, the more specific those queries can be: environment, release, and your own tags.
 
 For instance, a Traces query can display all the spans that occurred in the _production environment_, aggregated by the _customer-type custom tag_, and ordered by _p90(span.duration)_.
 
-Learn more in [Traces and Spans](/product/trace-explorer/).
+Learn more in [Explore](/product/explore/).
 
 ### Ownership Rules
 

diff --git a/docs/concepts/key-terms/extrapolation.mdx b/docs/concepts/key-terms/extrapolation.mdx
@@ -74,11 +74,11 @@ Extreme values like `min` and `max` aren't extrapolated because they're less sta
 
 While extrapolation is usually helpful, if you are exclusively looking to confirm your sampling usage or look exclusively at sampled data, you can turn off extrapolation.
 
-You can disable extrapolation using the settings icon above charts in tools like Trace Explorer. Note that with extrapolation off, your metrics will only reflect the sampled data, not your full traffic.
+You can disable extrapolation using the settings icon above charts in [Explore → Traces](/product/trace-explorer/). Note that with extrapolation off, your metrics will only reflect the sampled data, not your full traffic.
 
 <Alert>
 If Sentry displays a **low confidence warning**, it means there isn't enough sampled data for reliable extrapolation. Consider increasing your sample rate or widening your query filters.
 </Alert>
 
-![Trace Explorer low samples warning =500x](./img/Trace_explorer_low_samples.png)
+![Low sampling rate warning in Traces =500x](./img/Trace_explorer_low_samples.png)
 
diff --git a/docs/concepts/key-terms/key-terms.mdx b/docs/concepts/key-terms/key-terms.mdx
@@ -54,7 +54,7 @@ Each of these key features have their own page (or set of pages) in the [sentry.
 
 - **Projects** - Lists the projects of which you're a member, by team, and provides you with a high-level overview of your projects. From here, you can go to the **Project Details** page of each project for a more granular view. Learn more in the full [Projects documentation](/product/projects/).
 
-- **Explore** - Sentry offers multiple ways to search and investigate your application's data — including your app's [errors](/product/errors/), [traces](/product/trace-explorer/), [metrics](/product/metrics/), [profiles](/product/profiling/), [replays](/product/session-replay/), and [logs](/product/logs/) — to get the information you need to debug issues more quickly and easily.
+- **[Explore](/product/explore/)** - Sentry's home to search and investigate your application's data, including [errors](/product/errors/), [traces](/product/trace-explorer/), [metrics](/product/metrics/), [profiles](/product/profiling/), [replays](/product/session-replay/), and [logs](/product/logs/).
 
 - **Pre-built Sentry Dashboards** - Sentry surfaces insights that can help you identify opportunities at the service-level to improve various parts of your app's performance, including requests, assets, caches, queues, and more. Pre-built Sentry Dashboards living under the Dashboards heading provide an overview of how your project is performing in various categories, as well as the ability to review sample events and their traces to help you diagnose potential problems. Learn more in the full [Sentry Dashboards documentation](/product/dashboards/sentry-dashboards/).
 

diff --git a/docs/concepts/key-terms/tracing/distributed-tracing.mdx b/docs/concepts/key-terms/tracing/distributed-tracing.mdx
@@ -240,6 +240,6 @@ Dynamic sampling ensures complete traces by retaining all transactions associate
 
 ## Viewing Trace Data
 
-Use the [Trace Explorer](/product/trace-explorer/) to search for traces containing spans that meet your specific query conditions. This helps you find distributed traces that give you a connected view of your application and can help you debug and optimize your code.
+Use [Explore → Traces](/product/trace-explorer/) to search for traces containing spans that meet your specific query conditions. This helps you find distributed traces that give you a connected view of your application and can help you debug and optimize your code.
 
 Through [Dashboards](/product/dashboards/sentry-dashboards/) and [Traces](/product/trace-explorer/), you can also view trace data in the [Trace View](/concepts/key-terms/tracing/trace-view/) page.
diff --git a/docs/concepts/search/searchable-properties/events.mdx b/docs/concepts/search/searchable-properties/events.mdx
@@ -8,8 +8,8 @@ Events are the underlying event data captured using Sentry SDKs — that is, err
 
 You can search by event properties in the following [sentry.io](https://sentry.io) pages:
 
-- Errors - in the query builder
-- Trace Explorer - in the query builder
+- Explore → Errors - in the query builder
+- Explore → Traces - in the query builder
 - Dashboards - within the widget builder (depending on dataset selection)
 - Issues - as indicated in the list below
 - Alerts - when creating an alert

diff --git a/docs/concepts/search/searchable-properties/index.mdx b/docs/concepts/search/searchable-properties/index.mdx
@@ -4,22 +4,34 @@ description: "Learn more about searchable properties."
 sidebar_order: 10
 ---
 
-Sentry's search provides you with reserved keywords, like `is`, `user`, `server`, and `browser`, that you can use to search on the properties of issues, events and replays (as well as the special case of releases). You can also create [custom tags](#custom-tags) on which to search. This page provides guidance for how to use these properties and links you to the respective searchable property lists.
+Search keys depend on the dataset. A key that works on Errors can be invalid on Logs. This page links each place you search to the property list for that dataset. You can also search [custom tags](#custom-tags) and any attribute you attach in the SDK.
 
 ## Search Properties
 
-Sentry's searchable properties fall into one of five categories:
+### Explore
 
-- [Issue properties](/concepts/search/searchable-properties/issues/)
-- [Event properties](/concepts/search/searchable-properties/events/)
-- [Span properties](/concepts/search/searchable-properties/spans/)
-- [Session Replay properties](/concepts/search/searchable-properties/session-replay/)
-- [User Feedback properties](/concepts/search/searchable-properties/user-feedback/)
-- [Release properties](/concepts/search/searchable-properties/releases/)
+[Explore](/product/explore/) uses one search syntax and a different property list per dataset.
+
+- **Traces** use [span properties](/concepts/search/searchable-properties/spans/).
+- **Logs** use [log properties](/concepts/search/searchable-properties/logs/).
+- **Application Metrics** use [metric properties](/concepts/search/searchable-properties/metrics/).
+- **Errors** use [event properties](/concepts/search/searchable-properties/events/).
+- **Replays** use [session replay properties](/concepts/search/searchable-properties/session-replay/).
+- **Releases** use [release properties](/concepts/search/searchable-properties/releases/).
+- **Agents** use [span properties](/concepts/search/searchable-properties/spans/). Agent fields are attributes on spans.
+
+Profiles is a browse page. It does not have its own property list.
+
+### Issues and User Feedback
+
+Issues and User Feedback each have their own keys.
+
+- **Issues** uses [issue properties](/concepts/search/searchable-properties/issues/).
+- **User Feedback** uses [user feedback properties](/concepts/search/searchable-properties/user-feedback/).
 
 ## Search Tips
 
-Search terms should auto-complete, and when they don't that means you have an invalid dataset. If you enter an invalid search term and tap Return or Enter, an error message is displayed. For example, in **Errors** or **Trace Explorer**, you cannot search using a grouping function (properties with a parentheses in the key, for example `epm()`) if you don't already have a grouping function included in the "Results" table columns.
+Search terms should auto-complete, and when they don't that means you have an invalid dataset. If you enter an invalid search term and tap Return or Enter, an error message is displayed. For example, in **Errors** or **Traces**, you cannot search using a grouping function (properties with a parentheses in the key, for example `epm()`) if you don't already have a grouping function included in the "Results" table columns.
 
 When you search using a property that's a function, if the key includes a parameter, you still need to add a filter or value to have a complete search token. For example, the function `count_unique(field)` takes whichever field you choose as the parameter and then you add a number as your value to filter on. So a typical search might look like: `count_unique(user):>=20`.
 

diff --git a/docs/concepts/search/searchable-properties/logs.mdx b/docs/concepts/search/searchable-properties/logs.mdx
@@ -0,0 +1,209 @@
+---
+title: Log Properties
+description: "Learn more about searchable log properties."
+sidebar_order: 22
+---
+
+Search logs in [Explore → Logs](/product/logs/). The keys below are common properties set by Sentry or the SDKs. Any custom attribute you attach on the log is searchable too, using the same attribute name you set in the SDK.
+
+Raw text search matches `message` only. It does not search the rest of the log. Search is case sensitive by default. Use the **Ignore case** toggle in the search bar to match regardless of case. A regular expression uses `message://pattern//`. See [regular expressions](/concepts/search/#regular-expressions-logs-only).
+
+## Searchable Properties
+
+These keys can be used in a log search:
+
+<DefinitionList>
+
+### `message`
+
+The log message body.
+
+- **Type:** string
+
+### `message.template`
+
+The parameterized template, when the SDK recorded one. For example, `Adding item {item} for user {user}`.
+
+- **Type:** string
+
+### `message.parameter.<name>`
+
+One parameter from a parameterized message. `<name>` is the parameter name or the positional index, such as `message.parameter.item` or `message.parameter.0`.
+
+- **Type:** string or number, depending on the value the SDK sent
+
+### `severity`
+
+The severity text. One of `trace`, `debug`, `info`, `warn`, `error`, or `fatal`.
+
+- **Type:** string
+
+### `severity_number`
+
+The numeric severity. Higher numbers are more severe. SDKs set the low end of each range: `trace` is 1, `debug` is 5, `info` is 9, `warn` is 13, `error` is 17, and `fatal` is 21.
+
+- **Type:** number
+
+### `timestamp`
+
+When the log was recorded.
+
+- **Type:** datetime
+
+### `trace`
+
+The trace ID for the active trace when the log was recorded.
+
+- **Type:** string
+
+### `span_id`
+
+The span the log was emitted from. Empty when no span was active. Older SDKs send the same value as `trace.parent_span_id`.
+
+- **Type:** string
+
+### `id`
+
+The log's unique ID.
+
+- **Type:** string
+
+### `project`
+
+The project the log belongs to. You can also scope projects with the page filter.
+
+- **Type:** string
+
+### `environment`
+
+The environment set in the SDK, such as `development`, `staging`, or `production`. [Learn more](/concepts/key-terms/environments/).
+
+- **Type:** string
+
+### `release`
+
+The release set in the SDK. `release:latest` selects the most recent release. [Learn more](/product/releases/usage/sorting-filtering/#latest-release).
+
+- **Type:** string
+
+### `logger.name`
+
+The name of the logger that emitted the log, when the SDK or logging integration set one.
+
+- **Type:** string
+
+### `origin`
+
+Set when an SDK integration captured the log. For example, `auto.log.serilog` or `auto.db.prisma`. Direct calls to the Sentry logger API do not set this.
+
+- **Type:** string
+
+### `sdk.name`
+
+Name of the Sentry SDK that sent the log.
+
+- **Type:** string
+
+### `sdk.version`
+
+Version of the Sentry SDK that sent the log.
+
+- **Type:** string
+
+### `payload_size`
+
+Size of the log payload, in bytes.
+
+- **Type:** number
+
+### `replay.id`
+
+The ID of the active replay when the log was recorded.
+
+- **Type:** string
+
+### `browser.name`
+
+Display name of the browser. Relay parses this from the user agent when the SDK does not set it.
+
+- **Type:** string
+
+### `browser.version`
+
+Version of the browser.
+
+- **Type:** string
+
+### `user.id`
+
+Application-specific identifier for the user. Sent when [send default PII](/platform-redirect/?next=/data-management/data-collected/) is enabled, or when you set it yourself.
+
+- **Type:** string
+
+### `user.email`
+
+Email address of the user.
+
+- **Type:** string
+
+### `user.name`
+
+Username of the user.
+
+- **Type:** string
+
+### `server.address`
+
+Server address. Backend SDKs attach this.
+
+- **Type:** string
+
+### `os.name`
+
+Operating system name. Mobile, desktop, and native SDKs attach this.
+
+- **Type:** string
+
+### `os.version`
+
+Operating system version.
+
+- **Type:** string
+
+### `device.brand`
+
+Device brand.
+
+- **Type:** string
+
+### `device.model`
+
+Device model.
+
+- **Type:** string
+
+### `device.family`
+
+Device family.
+
+- **Type:** string
+
+### `code.file.path`
+
+File path captured with the log, when the SDK recorded a code location.
+
+- **Type:** string
+
+### `code.function.name`
+
+Function name captured with the log.
+
+- **Type:** string
+
+### `code.line.number`
+
+Line number captured with the log.
+
+- **Type:** number
+
+</DefinitionList>