What changed
Sentry announced on August 26, 2026 that its ingestion and web endpoints will change TLS certificate authorities in February 2027. Today those certificates are issued by DigiCert; after the cutover Sentry will use Google Trust Services and Let’s Encrypt. Sentry says domains and ordinary SDK connection behavior remain unchanged for almost all customers. The exceptions are integrations that pin Sentry’s certificate or issuing CA and older platforms that do not trust the Let’s Encrypt ISRG Root X1 certificate. Sentry will publish the exact cutover date later.
Why it matters
Observability is often most valuable during failures, so a telemetry client that silently loses TLS trust can turn an application incident into an observability blind spot. The change is routine PKI maintenance for modern systems but a hard compatibility boundary for pinned clients and legacy trust stores. Teams that ship embedded software, older mobile apps, long-lived Java services, restricted enterprise environments or custom proxies should test the trust path now rather than discovering the break after the certificate chain changes.
The hostnames stay stable while the trust anchors change
Sentry says customers will continue sending events to the same ingestion and web domains. The material change sits below the application protocol: DigiCert-issued certificates will be replaced by certificates from Google Trust Services and Let’s Encrypt. Standard operating systems and modern runtimes already trust those authorities, so most SDKs should reconnect normally when certificates rotate.
Certificate pinning becomes a guaranteed failure unless updated
Sentry explicitly says connections will fail after cutover if an integration pins the current Sentry certificate chain. Its recommended path is to remove pinning for Sentry domains; teams that must pin certificate authorities instead need to add the new GTS and Let’s Encrypt authorities before the transition. Hard-coding an individual leaf certificate would remain fragile after future rotations as well.
Old trust stores can also lose telemetry
Sentry calls out clients that do not trust Let’s Encrypt’s ISRG Root X1. Examples include Android versions before 7.1.1 and Java runtimes before JRE 8u141 or 7u151. Those are old platforms, but long-lived enterprise, appliance and embedded deployments can outlast ordinary application-upgrade cycles.
A successful app request does not prove Sentry telemetry works
Because the change affects the Sentry connection rather than the application’s own backend, production services can continue operating while errors, traces or other telemetry fail to upload. Teams with legacy clients should verify Sentry transport independently and alert on sustained ingestion drops rather than assuming the application’s primary connectivity covers the observability path.
The exact cutover day is still pending
Sentry has committed to February 2027 and says it will publish the precise date in another changelog entry and on its status page. Operators should complete trust-store and pinning work before February rather than wait for the final date, especially where client releases or appliance upgrades have long lead times.