GitHub Pages SSL Monitoring: Custom Domains, Org Pages, and the Enforce HTTPS Failure Mode

GitHub Pages is a static site hosting service built into GitHub. It serves files directly from a repository's branch, has no server configuration overhead, and provides automatic Let's Encrypt SSL for custom domains. For agencies managing portfolios of static sites — corporate websites, documentation sites, marketing pages — GitHub Pages is a common deployment target.

The SSL layer on GitHub Pages behaves differently from a Certbot setup or a managed hosting platform like Netlify. Understanding how GitHub provisions and renews certificates, and where provisioning fails silently, is necessary for agencies that want to monitor client GitHub Pages deployments before SSL failures reach visitors.

Types of GitHub Pages Deployments

GitHub Pages has three distinct deployment types, and each has different SSL characteristics:

User pages (<username>.github.io) are served from the <username>.github.io repository. The .github.io URL is served with GitHub's wildcard certificate. No custom SSL provisioning is needed for the default URL.

Organization pages (<orgname>.github.io) work the same way as user pages: served from the <orgname>.github.io repository, using GitHub's certificate for the .github.io domain.

Project pages (<username>.github.io/<project> or a custom domain) are served from any repository's gh-pages branch or docs/ folder. Project pages using the default .github.io/<project> URL share the user or organization certificate. Project pages with a custom domain require custom SSL provisioning.

For agencies managing client sites, the relevant deployment type is almost always a project page with a custom domain — the client's actual domain name (clientsite.com) rather than the GitHub subdomain.

The Custom Domain SSL Provisioning Process

When a custom domain is configured in GitHub Pages repository settings and "Enforce HTTPS" is enabled, GitHub initiates SSL provisioning:

GitHub verifies that the custom domain's DNS records point at GitHub Pages infrastructure
GitHub performs a Let's Encrypt HTTP-01 challenge to validate domain ownership
If validation succeeds, Let's Encrypt issues a certificate
GitHub Pages begins serving HTTPS with the new certificate

The challenge requires that HTTP requests to the custom domain reach GitHub's servers. For this to work, the DNS records must be configured correctly:

Apex domain (example.com): Four A records pointing to GitHub's IP range — 185.199.108.153, 185.199.109.153, 185.199.110.153, 185.199.111.153
Subdomain (www.example.com): A CNAME record pointing to <username>.github.io

GitHub validates all four A records for apex domains. Any missing record causes provisioning to fail.

The 24-Hour Provisioning Delay and the Silent Failure

GitHub Pages SSL provisioning is not instantaneous. After a custom domain is configured and DNS is updated, there is a processing delay before GitHub attempts the Let's Encrypt challenge. The delay varies — typically minutes to a couple of hours — but can extend longer under high demand.

During this delay, the GitHub Pages settings page shows an informational message about certificate provisioning. Once provisioning completes (success or failure), the message clears. The settings page does not persistently indicate whether the certificate was successfully issued or whether provisioning failed. The "Enforce HTTPS" checkbox remains checked in both cases.

This creates a scenario where an agency configures a custom domain, sees the informational message about provisioning, checks back hours later, sees the checkbox is checked and the message is gone, and assumes provisioning succeeded — when it may have failed due to incomplete DNS propagation or a partial A-record configuration.

The Four A-Record Requirement in Practice

Agencies encounter the four A-record requirement most often after client registrar or DNS provider migrations. When a client moves their domain from one provider to another, the DNS zone is rebuilt — and the four A records are frequently only partially restored.

Common failure modes:

Only one or two A records re-added. A client's IT team rebuilds the DNS zone from memory, adds the GitHub Pages IPs they can recall (or the ones returned by a quick search), and misses one or two of the four required addresses. GitHub validates all four during provisioning. If any of the four are absent, provisioning fails.

Wrong A records from outdated documentation. GitHub's IP range for Pages is documented, but search results surface outdated documentation from before GitHub updated their infrastructure IPs. Agencies or clients that use IP addresses from older documentation add records that point at the old range — which may no longer be active or may not be included in the Let's Encrypt validation check.

A records added to the wrong subdomain. When a client's domain uses a www redirect, the apex A records and the www CNAME need to be configured separately. Occasionally the A records are added to www.example.com rather than the apex example.com, or vice versa, leaving one configuration missing.

Cloudflare proxy enabled. When a client uses Cloudflare and enables the orange cloud proxy on their GitHub Pages domain, Cloudflare's IPs are returned for the domain's DNS resolution rather than GitHub's. GitHub's HTTP-01 validation cannot reach GitHub's servers through the Cloudflare proxy, and SSL provisioning fails. GitHub Pages requires DNS-only mode in Cloudflare (gray cloud).

Organization Pages and SSL Scoping

Organization pages with custom domains have the same SSL requirements as project pages with custom domains. However, the repository where the custom domain is configured is <orgname>.github.io rather than a named project repository.

For agencies that manage GitHub organizations on behalf of clients — setting up the organization, creating the Pages repository, and configuring the custom domain — the SSL configuration process is the same, but the repository is less visible. The <orgname>.github.io repository may not appear in typical code searches or repository lists depending on visibility settings.

The SSL monitoring implication: Organization page custom domain SSL is associated with the <orgname>.github.io repository. If a client's GitHub organization is transferred to another administrator, or if the organization's Pages settings are modified by the client directly, SSL provisioning can fail without the agency being aware of the repository-level change.

Certificate Renewal and the 90-Day Cycle

GitHub Pages certificates are issued by Let's Encrypt with a 90-day validity period. GitHub handles renewal automatically — typically renewing at approximately 60 days before expiry.

Renewal uses the same process as initial provisioning: an HTTP-01 challenge to the custom domain. The same DNS requirements apply. A domain that had all four A records configured at provisioning time may be missing one of them at renewal time if a client made DNS changes in the intervening weeks.

The renewal failure gap: Because renewal is attempted at approximately 60 days before expiry and the certificate has a 90-day validity period, a renewal failure that is not detected until the certificate expires means approximately 30 days of SSL failure. During those 30 days, the GitHub Pages site serves content with an expired certificate, and modern browsers block the site with a "Your connection is not private" warning.

Monitoring Approach for GitHub Pages Custom Domains

Effective monitoring for GitHub Pages custom domains needs to cover the specific DNS requirements for provisioning and renewal.

Monitor all four A records for apex domains. DNS change monitoring that validates all four GitHub Pages IP addresses is the earliest signal that a provisioning or renewal failure is pending. A DNS change that removes any of the four required A records should alert your team immediately — at the point of the DNS change, not 30 days later when the certificate expires.

Monitor www CNAME delegations separately from apex A records. The www CNAME pointing to <username>.github.io is a separate DNS requirement from the apex A records. Both are needed for full SSL coverage. Monitor them as separate checks.

Monitor SSL expiry with a 30-day threshold. SSL certificate monitoring with a 30-day expiry alert aligns with GitHub's renewal window. If GitHub's renewal attempt fails, the 30-day alert fires before the certificate expires. This gives time to investigate and correct the DNS issue.

Monitor GitHub Pages as a vendor. GitHub Pages infrastructure incidents can cause provisioning failures across multiple repositories simultaneously. Adding GitHub Pages as a vendor status feed distinguishes platform incidents from individual client DNS misconfigurations.

Watch for Cloudflare proxy changes. If a client uses Cloudflare for DNS management, DNS monitoring that detects changes to the A record resolution catches Cloudflare proxy enablement — the A records that were returning GitHub's IPs now return Cloudflare's IPs, which breaks both provisioning and renewal.

What a GitHub Pages Monitoring Setup Looks Like in Merlonix

For each GitHub Pages custom domain in Merlonix:

Add the apex domain as an asset with SSL certificate monitoring and a 30-day expiry alert. Add DNS change monitoring to detect any change to the four required A records.
Add the www subdomain as a separate asset. Monitor the CNAME delegation to <username>.github.io separately — a CNAME change that redirects www to a different host breaks GitHub Pages SSL independently from the apex A record configuration.
Set immediate DNS change alerts. A registrar migration or Cloudflare proxy change affecting a GitHub Pages domain should alert the same day.
Add GitHub Pages as a vendor status feed to separate platform incidents from DNS misconfigurations.

Merlonix is built for agency portfolio monitoring — SSL expiry alerts, DNS change detection, vendor status tracking, and per-client alert routing. Start a free trial and add your first GitHub Pages custom domain.