September 2026 Summaries

Etsy’s approach to preparing its mobile apps for holiday traffic focuses less on capacity and more on mitigating problems that cannot be quickly reverted once embedded in an app release. Rather than enforcing a full code freeze, it uses a phased “code slush” beginning in October that progressively raises release requirements, culminating in senior approval for peak-season changes. The company preserves operational flexibility through experimentation and operational flags, rarely using forced upgrades, and audits whether risky code paths can actually be disabled remotely. To avoid disruption, Etsy ran old and new crash-reporting tools in parallel through the holidays, while refining alerting so only major crash-rate deviations trigger urgent incidents and less urgent signals are routed for later review. It adds custom tags such as the user’s last screen and experiment context to align code-based crash reports with teams responsible for product surfaces, and investigates issue trends collectively to identify shared causes such as releases or experiment ramps. Etsy also translates crash rates into estimated business impact to support prioritization and observability investment, and develops automation only after teams have manually established and measured an effective triage process.

Sentry has expanded its beta Seer Agent from an information-gathering debugging assistant into a tool that can take approved actions within Sentry, including creating dashboards, monitors, and alerts; managing issues; and saving queries and views. The agent operates under the user’s existing permissions, requests authorization when additional write access is needed, and does not retain permissions after a chat session. Seer Agent can also incorporate external infrastructure data from Datadog and Google Cloud Platform through new connectors, allowing it to correlate application and infrastructure signals for more complete diagnoses, although connections currently require API keys rather than OAuth. Available in the Sentry interface and through Slack, the free beta aims to help teams continuously organize projects, monitor services, diagnose incidents, and automate debugging-related workflows.

Sentry’s opt-in bfcacheMetricsIntegration, introduced in JavaScript SDKs v11, makes browser back/forward cache behavior measurable through application metrics, addressing a gap in conventional page-load telemetry where successful instant restorations produce little or no trace. The browser’s bfcache preserves a page’s DOM, JavaScript state, and scroll position in memory, enabling near-instant back and forward navigation, while misses require a full reload that can harm user experience, particularly on slower devices or networks. Because cache eligibility can be affected by changing browser heuristics, application code, headers, connections, and embedded content, the integration tracks navigation outcomes, Chromium-specific reasons a page was not restored, and the duration of fallback reloads to show both causes and user impact. Teams can enable it with a single SDK integration and use custom dashboards to monitor hit rates, identify affected routes, investigate blocker reasons, and prioritize fixes, while Sentry plans to extend bfcache awareness into areas such as Core Web Vitals.

Sentry’s Search Query Assistant translates natural-language requests into Sentry Search Syntax, and its non-deterministic outputs are evaluated against core user scenarios to identify and correct failures. While simple issues can be debugged locally through JSON outputs and mock tool calls, more complex problems involving live data, model versions, or infrastructure benefit from Sentry’s AI Conversation view, which exposes prompts, LLM generations, tool calls, timelines, and related backend traces. In one production issue, the assistant failed to return events for a custom numerical attribute because its prompt displayed the field name incorrectly rather than in the required typed search-syntax format; tracing revealed the problem in how API tool-call results were incorporated into the system prompt. After creating a reproducing evaluation, deploying a fix, and verifying corrected prompts and API parameters in production, the team also began sending local evaluation traces to Sentry, allowing developers to inspect agent behavior with the same familiar observability tools used for conventional application errors.

A developer of Cliparr, a self-hosted browser-based video clipping tool, used Sentry Application Metrics to evaluate and improve output file-size estimates without collecting users’ media or modifying self-hosted installations. By extracting the conversion engine into the public, static Cliparr Convert website and anonymously recording numeric metrics such as estimated-versus-actual size ratios, output formats, conversion quality, and completion status, the developer found that an AI-generated estimator based on resolution could underestimate files by as much as 83%. Replacing it with the standard bitrate-times-duration calculation brought estimates to within roughly 5% for transcoded videos, while the metrics also revealed that copy-mode exports were overestimated by about 16% and GIF estimates were consistently high by around 9%. The collected data showed MP4 was the most common output format and that users often converted files for compatibility rather than compression, while conversion counters showed no failures in the initial dataset. The project also instruments a progressive web app installation funnel to measure availability, prompts, acceptance, and completed installations across desktop, Android, and iOS.