SSL Monitoring for Jekyll Sites on GitHub Pages: The 4 A-Record Requirement and Silent Provisioning Failures

Jekyll is the static site generator built into GitHub Pages. For agencies building and maintaining client Jekyll sites, GitHub Pages is often the first deployment target — it is free for public repositories, integrates with the standard GitHub workflow, and handles SSL through an automated Let's Encrypt integration. The operational surface appears simple: push code, GitHub builds the site, SSL is managed automatically.

The reality is more specific. GitHub Pages has a particular set of DNS requirements for custom domain SSL, and when those requirements are partially met — as they often are after a client changes registrar or DNS provider — SSL provisioning fails silently in a way that the GitHub repository settings UI does not clearly communicate.

How GitHub Pages Provisions SSL for Custom Domains

When a custom domain is configured in a GitHub Pages repository, GitHub attempts to provision a Let's Encrypt certificate for that domain. The provisioning process requires two things: the custom domain must be entered in the repository's Pages settings, and the DNS records for the domain must point at GitHub Pages infrastructure.

GitHub uses Let's Encrypt's HTTP-01 challenge to provision certificates. For this to succeed, HTTP requests to the custom domain must route to GitHub Pages servers — which means the DNS records must be correctly configured and propagated before provisioning is attempted.

For apex domains (example.com, without www), GitHub Pages requires 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

GitHub Pages validates all four IP addresses during SSL provisioning and renewal. If any of the four are missing or if any A record points at a different IP, provisioning fails.

For www subdomains, a single CNAME record pointing to <username>.github.io is required.

The Silent Failure Mode: "Enforce HTTPS" Stays Checked

The most common SSL problem for Jekyll agencies on GitHub Pages is provisioning that appeared to succeed but didn't. When a custom domain is configured and "Enforce HTTPS" is enabled in repository settings, the checkbox is checked regardless of whether Let's Encrypt successfully issued a certificate.

GitHub Pages shows a warning message — "Certificate provisioning in progress" or a similar note — when provisioning is pending. But this message disappears whether provisioning succeeded or failed. After the message clears, the repository settings page does not distinguish between "certificate active and serving" and "certificate provisioning failed and the site is serving without SSL."

When this happens in practice:

A client migrates their domain from GoDaddy to Cloudflare Registrar. During the migration, the DNS zone is rebuilt from scratch. The client or their IT team manually re-adds the A records, but adds only two of the four required GitHub Pages IP addresses — the two they remembered, or the two returned by a quick search that returned a dated list. The agency enables "Enforce HTTPS" in repository settings. GitHub attempts SSL provisioning, finds that two of the four required A records are missing, and fails. The checkbox shows as enabled. The site serves content, but over HTTP with a redirect that browser security policies may flag, or with the old certificate continuing to serve until it expires.

The 4 A-Record Requirement After Registrar Migrations

Client registrar migrations are the most common trigger for the 4 A-record problem. When a client moves domain management from one registrar to another, the DNS zone is frequently rebuilt manually. The rebuild process introduces errors:

Only 1 or 2 of the 4 GitHub IP addresses are re-added
The records are added with incorrect TTL values that delay propagation
The A records are added to the wrong zone (the www subdomain rather than the apex)
A CNAME is added for the apex domain instead of A records, which is not valid for apex domains in most DNS configurations

GitHub Pages checks all four A records each time it renews the Let's Encrypt certificate (at approximately 60 days before expiry). If any of the four records are missing at renewal time, the renewal fails. The existing certificate continues serving until it expires. The missing record failure is not surfaced in the GitHub repository settings — the "Enforce HTTPS" checkbox remains checked.

DNS Changes That Reset SSL Provisioning

Beyond registrar migrations, several DNS changes trigger SSL re-provisioning on GitHub Pages:

Changing DNS providers. Moving from registrar-provided DNS to Cloudflare, or from Cloudflare to another provider, requires the DNS zone to be rebuilt. The same 4 A-record requirement applies during the re-provisioning attempt.

Adding Cloudflare proxying. When a client enables Cloudflare's proxy (the orange cloud) on a domain pointing at GitHub Pages, the DNS resolution changes — Cloudflare returns its own IP addresses rather than GitHub's. GitHub Pages cannot validate ownership through the Cloudflare proxy and SSL provisioning fails. GitHub Pages requires DNS-only mode (gray cloud) in Cloudflare for custom domain SSL to work.

Client-side DNS management. Agencies that transfer repository management to a client while retaining DNS management see breakage when the client independently updates their DNS records for another purpose and removes or changes the GitHub Pages A records.

Monitoring Approach for Jekyll Agencies on GitHub Pages

The specific monitoring setup for Jekyll sites on GitHub Pages needs to address both the A-record requirement and the silent provisioning failure mode.

Monitor all four A records explicitly. DNS change monitoring on GitHub Pages apex domains should validate that all four GitHub IP addresses are present and that no additional A records pointing at other IPs have been added. A change to any of the four A records is the earliest signal that SSL renewal will fail at the next renewal cycle.

Monitor the CNAME delegation for www subdomains. The www CNAME pointing to <username>.github.io must remain intact. If a client's registrar migration rebuilds the zone and the CNAME is replaced with an A record pointing at a different host, GitHub Pages SSL renewal fails for the www subdomain.

Monitor SSL expiry with a 30-day threshold. SSL certificate monitoring with a 30-day expiry alert gives enough lead time to correct a missing A record before the current certificate expires. GitHub Pages Let's Encrypt certificates have a 90-day validity period — a 30-day alert gives a 60-day buffer to identify and fix the DNS issue.

Monitor GitHub Pages as a vendor. Add GitHub Pages as a vendor status feed. GitHub Pages infrastructure incidents can cause SSL provisioning failures across multiple client repository deployments simultaneously. Seeing a GitHub Pages platform event changes your response — you wait for the incident to resolve rather than investigating client-specific DNS configurations.

Verify Cloudflare proxy settings when Cloudflare is the DNS provider. If a client uses Cloudflare for DNS management, DNS monitoring that detects a CNAME change or A record resolution change will also detect when the Cloudflare proxy is enabled. Cloudflare-proxied domains return Cloudflare IP addresses, not GitHub Pages IPs — the DNS monitoring alert is the signal that a client has changed their Cloudflare proxy setting in a way that breaks GitHub Pages SSL.

What a Jekyll Monitoring Setup Looks Like in Merlonix

For each Jekyll client on GitHub Pages 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 with SSL and DNS monitoring. Monitor the CNAME record separately from the apex A records — they are independent requirements.
Enable DNS change alerts with immediate notification. A registrar migration or DNS provider change that removes any of the four GitHub Pages A records should alert your team the same day, not 90 days later at the renewal cycle.
Add GitHub Pages as a vendor status feed to distinguish platform incidents from individual client DNS changes.

For Jekyll agencies that include site maintenance as part of a retainer, this configuration is a concrete deliverable: the client's GitHub Pages deployment is monitored at both the DNS and SSL layers, with alerts before any GitHub Pages provisioning failure reaches a visitor.

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 Jekyll client domain.