## DESCRIBE YOUR PR

Python SDK
[2.68.1](https://github.com/getsentry/sentry-python/releases/tag/2.68.1)
restored `enable_logs` as a deprecated compatibility layer
([sentry-python#7237](getsentry/sentry-python#7237)),
walking back part of the removal documented in #19029. Our docs still
describe the option as a no-op.

Concretely, in 2.68.1 the `capture_sentry_logs` default changed from
`False` to an internal sentinel, and the "`enable_logs` has no effect"
warning was removed from `client.py`. So when an integration leaves
`capture_sentry_logs` unset, `enable_logs=True` turns automatic log
capture back on for the `logging` and Loguru integrations, while an
explicit `capture_sentry_logs` always wins:

| `enable_logs`     | `capture_sentry_logs` | Automatic capture |
| ----------------- | --------------------- | ----------------- |
| not set / `False` | not set               | off               |
| `True`            | not set               | on                |
| any               | `True`                | on                |
| any               | `False`               | off               |

Two user-facing consequences of the stale docs: users on
`enable_logs=True` are told their config has no effect when it does, and
users debugging missing logs are pointed only at the new option.

- Rewrite the `enable_logs` entry in the Python options reference as
**deprecated** rather than a no-op, with the precedence table above
- Note that `2.68.0` alone had no effect, so anyone relying on the
option upgrades to `2.68.1`+
- Correct the `capture_sentry_logs` default on both the `logging` and
Loguru integration pages from `False` to unset, and explain the
`enable_logs` fallback
- Mention the deprecated path in both "Logs not appearing in Sentry"
troubleshooting entries
- Reword the level-threshold sentences that were conditioned on
`capture_sentry_logs is True`

Not included: `DjangoIntegration(failed_request_status_codes=...)`
shipped in the same release
([sentry-python#7140](getsentry/sentry-python#7140))
and is undocumented, but it's an unrelated option — worth a separate PR.

## IS YOUR CHANGE URGENT?

Help us prioritize incoming PRs by letting us know when the change needs
to go live.
Select exactly one option. For deadlines, replace `YYYY-MM-DD` with the
due date. You can update this information later by editing the PR
description.

- [ ] Urgent deadline (GA date, etc.): YYYY-MM-DD
- [ ] Other deadline: YYYY-MM-DD
- [x] No deadline: Not urgent, can wait up to 1 week+

## SLA

- Teamwork makes the dream work, so please add a reviewer to your PRs.
- Please give the docs team up to 1 week to review your PR unless you've
supplied a deadline.

Thanks in advance for your help!

## PRE-MERGE CHECKLIST

_Make sure you've checked the following before merging your changes:_

- [ ] Checked Vercel preview for correctness, including links
- [ ] PR was reviewed and approved by any necessary SMEs (subject matter
experts)
- [ ] PR was reviewed and approved by a member of the [Sentry docs
team](https://github.com/orgs/getsentry/teams/docs)

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

## DESCRIBE YOUR PR

Python SDK
[2.68.1](https://github.com/getsentry/sentry-python/releases/tag/2.68.1)
restored `enable_logs` as a deprecated compatibility layer
([sentry-python#7237](getsentry/sentry-python#7237)),
walking back part of the removal documented in #19029. Our docs still
describe the option as a no-op.

Concretely, in 2.68.1 the `capture_sentry_logs` default changed from
`False` to an internal sentinel, and the "`enable_logs` has no effect"
warning was removed from `client.py`. So when an integration leaves
`capture_sentry_logs` unset, `enable_logs=True` turns automatic log
capture back on for the `logging` and Loguru integrations, while an
explicit `capture_sentry_logs` always wins:

| `enable_logs`     | `capture_sentry_logs` | Automatic capture |
| ----------------- | --------------------- | ----------------- |
| not set / `False` | not set               | off               |
| `True`            | not set               | on                |
| any               | `True`                | on                |
| any               | `False`               | off               |

Two user-facing consequences of the stale docs: users on
`enable_logs=True` are told their config has no effect when it does, and
users debugging missing logs are pointed only at the new option.

- Rewrite the `enable_logs` entry in the Python options reference as
**deprecated** rather than a no-op, with the precedence table above
- Note that `2.68.0` alone had no effect, so anyone relying on the
option upgrades to `2.68.1`+
- Correct the `capture_sentry_logs` default on both the `logging` and
Loguru integration pages from `False` to unset, and explain the
`enable_logs` fallback
- Mention the deprecated path in both "Logs not appearing in Sentry"
troubleshooting entries
- Reword the level-threshold sentences that were conditioned on
`capture_sentry_logs is True`

Not included: `DjangoIntegration(failed_request_status_codes=...)`
shipped in the same release
([sentry-python#7140](getsentry/sentry-python#7140))
and is undocumented, but it's an unrelated option — worth a separate PR.

## IS YOUR CHANGE URGENT?

Help us prioritize incoming PRs by letting us know when the change needs
to go live.
Select exactly one option. For deadlines, replace `YYYY-MM-DD` with the
due date. You can update this information later by editing the PR
description.

- [ ] Urgent deadline (GA date, etc.): YYYY-MM-DD
- [ ] Other deadline: YYYY-MM-DD
- [x] No deadline: Not urgent, can wait up to 1 week+

## SLA

- Teamwork makes the dream work, so please add a reviewer to your PRs.
- Please give the docs team up to 1 week to review your PR unless you've
supplied a deadline.

Thanks in advance for your help!

## PRE-MERGE CHECKLIST

_Make sure you've checked the following before merging your changes:_

- [ ] Checked Vercel preview for correctness, including links
- [ ] PR was reviewed and approved by any necessary SMEs (subject matter
experts)
- [ ] PR was reviewed and approved by a member of the [Sentry docs
team](https://github.com/orgs/getsentry/teams/docs)

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>