August 2026 Summaries

Sentry is replacing the deprecated boolean `sendDefaultPii` option with the more granular `dataCollection` configuration across its SDKs, beginning with JavaScript SDK version 11, where the new setting becomes the default. Unlike the prior all-or-nothing switch, `dataCollection` lets developers independently control categories such as user information, cookies, HTTP headers and bodies, query parameters, GenAI inputs and outputs, and database query data, with allowlists and denylists available for certain key-value fields. JavaScript v11 defaults collect substantially more data than v10 configurations with `sendDefaultPii` disabled, including user information, cookies, complete truncated HTTP bodies, GenAI content, and database query data, although sensitive credentials remain automatically filtered or excluded. Developers upgrading from `sendDefaultPii: true` can generally remove the old setting, while those relying on v10’s restrictive defaults must explicitly configure `dataCollection` to preserve them. The update also clarifies that manually attached data is still sent regardless of automatic collection settings, and recommends `beforeSend`, `beforeSendSpan`, and `ignoreSpans` for custom redaction or span filtering as v11 enables span streaming by default.

Session replay software can serve either UX analytics, focused on user behavior and visual analysis, or developer debugging, focused on correlating user actions with application errors and system state. Selecting a tool requires evaluating its recording method, with DOM-based event capture generally offering stronger compression, client-side privacy masking, structured data analysis, and debugging integrations, while pixel capture can provide more faithful visual playback for complex interfaces. Privacy considerations include whether sensitive information is masked before leaving the browser or only after reaching vendor servers, alongside consent, residency, compliance, and SDK transparency requirements. Engineering teams may benefit most from tools that link replays directly to errors, traces, network activity, and console data, while performance overhead should be measured on the organization’s own application and managed through sampling strategies that prioritize error sessions. Structured replay data may also better support AI-assisted investigation than video-based recordings, and organizations with significant mobile traffic should assess native SDK coverage, masking, error correlation, and battery and CPU impact. The appropriate choice ultimately depends on the main users, regulatory environment, existing observability systems, mobile requirements, and whether the priority is product research or production debugging.

A daily Claude Routine uses the Sentry MCP to analyze hundreds of Seer agent conversations and thousands of tool calls from the prior night, automatically identifying errors, unusual costs or latency, excessive tool use, and potential reasoning failures before the team begins work. Replacing a manual process that required extracting and parsing raw Langfuse trace data, the routine gathers aggregate metrics, samples both failed and successful conversations, examines underlying spans and source code, produces a report, checks Linear for existing issues, and files tickets for newly discovered problems. Its combination of aggregate error analysis and detailed conversation review revealed recurring cases in which the agent guessed incorrect repository or project identifiers, as well as backend latency issues, enabling targeted fixes such as supplying repository names directly. The experience suggests that reviewing successful runs alongside failures is essential for validating agent conclusions, while delegating data retrieval to Sentry and judgment to Claude creates a more consistent and efficient monitoring workflow.

Sentry describes an automated debugging and issue-triage workflow designed to manage the growing volume of AI-generated code fixes without increasing engineers’ manual workload. Its Seer AI agent monitors instrumented applications, diagnoses issues, proposes fixes, and can open GitHub pull requests, with organizations able to choose how much human oversight is required. To ensure generated PRs are reviewed, Sentry uses a scheduled Claude routine that scans Slack notifications, asks Seer to identify the most relevant reviewer based on repository history, verifies that each PR remains open, and prompts the reviewer to merge or close it while leaving brief feedback. After several weeks of iteration to avoid duplicate messages and inappropriate notifications, the workflow showed early improvements in PR action rates and 48-hour response rates, while more PRs closed without merging were largely attributed to duplicate or broader alternative fixes rather than poor proposals. Sentry emphasizes that successful automation depends on routing work to the right people at the right time and notes that the required components, including Seer, Slack, GitHub, and automation tools such as Claude or Cursor, are available for others to implement.

Sentry’s OtlpIntegration connects OpenTelemetry tracing with Sentry’s error, log, metric, and event data, addressing the lack of shared context when applications use a standalone OTel SDK and export spans directly through Sentry’s OTLP endpoint. Available across major backend SDKs, it configures OTLP exporting, attaches active OTel trace and span IDs to Sentry events, and thereby enables users to navigate between errors and the traces or spans associated with them. This approach replaces Sentry’s former deeply integrated POTel model for most languages, favoring independent, portable SDKs over in-process interleaving of Sentry and OTel spans, while Java retains POTel as its primary long-term option and Node.js is moving toward lighter native instrumentation. The integration is aimed at teams already using OTel, especially polyglot organizations, and allows them to retain their existing tracing infrastructure while adding Sentry error monitoring; however, exceptions still require a Sentry SDK rather than OTLP alone, duplicate tracing should be avoided, and future Sentry propagation support will require explicit user configuration.