Stuck in 'New': Diagnosing GitHub Pages SSL Provisioning Delays for Software Engineer OKRs

When Your GitHub Pages SSL Certificate Gets Stuck in 'New'

For any software engineer, ensuring a secure and available web presence is often a key result within their broader software engineer OKR. So, when a critical component like an HTTPS certificate stalls, it can be a significant roadblock. A recent GitHub Community discussion highlighted just such a frustrating scenario: a GitHub Pages custom domain's HTTPS certificate stuck in the "new" state for days, well past the typical provisioning window.

The user, axonturk, reported their custom domain (bildesk.com.tr) had its HTTPS certificate stuck, with the API response showing "https_certificate":{"state":"new","description":"This domain was recently added. The certificate request process will begin shortly."} and "https_enforced":false. This wasn't just an inconvenience; it meant their site lacked essential HTTPS security.

The Crucial Diagnosis: Checking Certificate Transparency Logs

What made this discussion particularly insightful was the detailed troubleshooting. axonturk had already verified all common client-side issues:

• Domain verified at account level.
• Correct DNS A records, no AAAA, no CAA blocking Let's Encrypt, no DNSSEC.
• No conflicting CNAME/ALIAS.
• Plain HTTP served the site perfectly.

The breakthrough came from checking Certificate Transparency (CT) logs (e.g., crt.sh, Cert Spotter). These logs showed zero issuance attempts for the domain. As community member SirHegel eloquently explained, this detail was definitive: if GitHub had even attempted to provision the certificate, a failed order would appear in the CT logs, or the API state would be errored. The absence of any attempt meant the request never even left GitHub's internal systems.

This is a vital lesson for any software engineer: when debugging external service integrations, always check the logs of the external service itself if possible. It quickly narrows down whether the issue is upstream or downstream.

What NOT to Do: The Retrigger Trap

A common instinct when something is stuck is to retry. axonturk initially tried removing and re-adding the custom domain. SirHegel strongly advised against this:

removing and re-adding the custom domain does not retrigger anything useful. It deletes the pending request and creates a new one at the back of the same queue, so each attempt costs you your place in line. If the queue is the problem, retrying is strictly counterproductive.

This highlights a critical aspect of developer productivity: understanding system behavior to avoid actions that inadvertently worsen the situation. Patience and informed action are key.

Getting a Quick Resolution: What to Tell Support

When an issue is clearly on the platform's side, effective communication with support is paramount. SirHegel provided an excellent template for a support ticket that minimizes back-and-forth:

- Repository and custom domain
- The full GET /repos/{owner}/{repo}/pages response, verbatim, with the timestamp you took it
- The exact time the domain was last saved
- That CT logs show no issuance attempt — name the tools you checked, crt.sh and Cert Spotter
- That you have stopped retriggering, and when you last did
- Explicitly: "the certificate request appears never to have been enqueued; please requeue it"

The final line is particularly important as it directs support to the exact system that needs attention, significantly improving the chances of a same-day fix. This structured approach to problem reporting is a valuable developer KPI example for efficient incident resolution.

A Temporary Stopgap (with Caveats)

If immediate HTTPS is critical, a temporary workaround involves placing Cloudflare in front of GitHub Pages with proxying enabled. However, SirHegel cautioned about the security implications:

with no certificate on the Pages side, you would be running Cloudflare's SSL mode in Flexible, which encrypts browser-to-Cloudflare and leaves Cloudflare-to-GitHub in plaintext. For a brochure site that is a reasonable trade for a few days. For anything with a login form or a session cookie it is not, and I would rather sit on plain HTTP than advertise a padlock that stops halfway.

This pragmatic advice underscores the trade-offs software engineers often face when balancing immediate availability with security best practices, a common challenge when striving to meet deployment-related software engineer OKRs.

This discussion provides a clear roadmap for diagnosing and escalating GitHub Pages SSL issues, emphasizing the power of systematic debugging and precise communication for maintaining developer productivity and achieving robust deployment goals.