Between the morning of 21 August and the early hours of 23 August 2026 (UTC), five customer websites could not be reached securely. Visitors to those sites would have seen a browser security warning or an error page instead of the site. All other sites continued to work normally throughout.

Websites use a digital certificate to enable the padlock in the address bar. These certificates renew automatically. During an internal maintenance change, our system requested a large number of new certificates at once, and the certificate provider declined most of the requests because they arrived too quickly. Those requests did not retry on their own, so some certificates were never renewed.

We fixed the underlying configuration, moved the affected sites onto a corrected renewal process, and confirmed every one of them was working again by 00:49 UTC on 23 August.

No customer information was accessed, changed, or lost, and no accounts were affected. The problem only prevented certificates from renewing.

We are sorry for the disruption. We are changing how this type of maintenance is carried out so it cannot repeat, and adding monitoring so that a stalled renewal is detected in minutes rather than discovered later.

_____________________________________________________________

Technical Details:

Summary. Between 06:03 UTC on 21 August and 00:49 UTC on 23 August 2026, five customer sites were unreachable over HTTPS. All other sites remained available throughout. The issue has been fully resolved.

Cause. An internal infrastructure change was applied in a way that caused part of our platform configuration to be rebuilt rather than updated in place. The rebuild triggered a large number of simultaneous TLS certificate requests to our certificate authority, which rejected most of them under its published rate limits for new account registrations. The rejected requests did not automatically retry, so the affected certificates were never issued.

Impact. Five sites presented no valid TLS certificate and could not complete an HTTPS connection, affecting eight hostnames in total. Sites served through a content delivery network that terminates TLS at its own edge were unaffected and continued to serve normally.

No customer data was accessed, altered, or lost at any point. No credentials were exposed. The fault was limited to certificate issuance and did not affect application data, databases, or backups.

Resolution. We corrected two configuration defects in our consolidated certificate issuance path and migrated the affected domains onto it. That path uses a single certificate authority account and is not subject to the registration limit that caused the failure. All affected sites were confirmed serving valid certificates by 00:49 UTC on 23 August.

Prevention. We are making the following changes:

• Infrastructure changes that rename or re-type a resource will use explicit state-migration directives, so that a rename can never be executed as a delete and recreate. Any change whose plan would remove a configuration container is now subject to mandatory review.
• We are consolidating all certificate issuance onto the single-account path used for recovery, removing the per-domain account model that made the rate limit reachable.
• We are adding monitoring for stalled certificate issuance. In this incident, issuance had been stalled for 36 hours without an alert, and our internal dashboard classified the stalled certificates as still in progress. Both are being corrected.