Visit Group Says Its Certificate Renewal Automation Had Been Silently Failing for an Extended Period, With No Alerting in Place

Visit Group posted an incident report on its status page on July 13, 2026, about an outage on the morning of July 10. The report gives the incident's duration as approximately "6 hours 20 minutes." During it, all customers using the affected booking services "were unable to complete online bookings during the incident window." Parts of the report follow, not the whole.

Root Cause Analysis

The outage, the report says, "was caused by the expiry of TLS certificates" used by the company's booking services. Those certificates are "managed by an internal automated renewal service running on a production server." The investigation found that this renewal service "had been crash-looping continuously and had never successfully completed an automated renewal cycle."

Not once.

The service "was pinned to a specific version of the .NET 6 runtime that was not installed on the production host, preventing the application from starting." So, the report says, "certificates were never renewed before they expired." A secondary contributing factor was "a misconfigured port in the server's reverse proxy, which meant the renewal endpoint was not correctly reachable even when the service was running." And "The failure was visible in deployment logs, but no monitoring or alerting was in place to surface it before customer impact occurred."

Timeline

The report's timeline begins at 02:06 CEST with the "First customer report received via support line," a booking failing with an error, and the customer confirmed the same error on five other hotel sites using the platform. Internal confirmation came at 08:02 CEST: all sites on one of its booking products were down, and another service was failing with a certificate validation error. Engineering and platform leadership were engaged at 08:22, and a manual certificate renewal was started on the production server.

The time between the first customer report and the company's internal response, which the report puts at "approximately six hours," it calls "not acceptable."

Next Steps and Conclusion

The report's preventive measures and next steps are five. Replace or fully harden the renewal service "with a clear owner and operational runbook." Put in "proactive monitoring and alerting for certificate expiry (minimum 30 days' notice), renewal failures, and renewal-service health." Ensure that required runtimes "are validated as part of the deployment pipeline, with startup smoke tests to catch failures early." Establish clear ownership of the renewal service within the platform team, with defined on-call responsibilities and a reviewed runbook. And review the first-response process for overnight support contacts, so that multi-tenant production issues "are escalated to engineering faster."

In its conclusion, the report says the automation "had been silently failing for an extended period due to a missing runtime dependency and a misconfigured network port, with no alerting in place to surface the problem before it reached production impact."