The Weekend Certificate Expiration Pattern
The Weekend Certificate Expiration Pattern
Certificate monitoring data reveals an interesting pattern: expirations aren't distributed evenly across the week. This analysis examines production data from thousands of websites to understand a pattern affecting organizations globally.
The Starting Hypothesis
Common wisdom suggests that certificate expirations should be uniformly distributed throughout the week. After all, certificates are issued continuously throughout the year, and the day of the week when they're issued (and therefore expire) should be essentially random.
If this assumption holds true, one would expect to see:
- About 14% of expirations each day of the week
- Roughly 28.6% occurring on weekends (Saturday and Sunday)
This analysis tests that assumption with real production data.
The Data Set
Certificate monitoring services continuously track live SSL/TLS certificates across thousands of websites. For each monitored host, the system periodically checks the certificate and records lifecycle events:
- Renewal events: When a certificate is replaced with a new one before expiration
- Expiration events: When a certificate expires while still being served by the host
- Discovery events: When new certificates are detected (through Certificate Transparency logs or manual addition)
This continuous monitoring approach captures the real-world lifecycle of certificates in production environments. Rather than looking at theoretical expiration dates in isolation, this analysis tracks what actually happens to certificates that are actively serving traffic.
This analysis examined:
- 5,162 certificate expirations - certificates that expired while still in active use
- 134,563 successful certificate renewals - certificates replaced before expiration
- 133 days of continuous monitoring (June through October 2025)
- Globally distributed hosts across all timezones
The key distinction: an "expiration" in this data means a certificate that was still serving traffic when its validity period ended. These represent actual operational failures, not certificates that were decommissioned or replaced before expiring.
This sample size is large enough to reveal real patterns and distinguish them from random noise.
The First Finding: Weekend Clustering
Plotting certificate expirations by day of week reveals something unexpected:
| Day of Week | Expirations | Percentage |
|---|---|---|
| Sunday | 581 | 11.3% |
| Monday | 441 | 8.5% |
| Tuesday | 484 | 9.4% |
| Wednesday | 453 | 8.8% |
| Thursday | 382 | 7.4% |
| Friday | 1,052 | 20.4% |
| Saturday | 1,769 | 34.3% |
Weekend total: 45.5% (vs. expected 28.6%)
This represents nearly double the expected rate for weekends. Saturday alone accounts for more than one-third of all certificate expirations, making it the single day with the highest risk.
Statistical testing confirmed this isn't random variation (p < 0.0001). This is a real pattern.
Looking at Successful Renewals
To understand why expirations cluster on weekends, examining the opposite pattern helps: when do certificates get successfully renewed?
Certificate renewals happen in two ways:
- Automated renewals: ACME clients (like Let's Encrypt's certbot), cert-manager, or custom automation renewing certificates programmatically
- Manual renewals: Administrators manually requesting and installing new certificates
Since certificates are issued continuously throughout the year, and automated renewal systems run on fixed schedules (not synchronized to days of the week), automated renewals should be distributed evenly across all days, just like the expirations should be.
The renewal data reveals something important:
99.5% of certificate renewals (133,874 out of 134,563) occur more than 4 weeks before expiration, evenly distributed across days of the week. This signals highly automated renewals, consistent with Let's Encrypt's recommendation to renew at 30 days before expiration.
What about the remaining 0.5% of renewals that happen within the final 28 days before expiration?
Analysis of these 553 "late renewal" events shows:
| Day of Week | Late Renewals | Percentage |
|---|---|---|
| Sunday | 17 | 3.1% |
| Monday | 32 | 5.8% |
| Tuesday | 73 | 13.2% |
| Wednesday | 71 | 12.9% |
| Thursday | 93 | 16.9% |
| Friday | 146 | 26.5% |
| Saturday | 120 | 21.7% |
Weekend total: 24.95% (below expected 28.6%)
This reveals something interesting: late renewals show a slight weekday bias. This can be attributed to more manual renewals occurring in the final 28 days, though certainty is impossible.
The Mirror Pattern
Comparing these patterns side by side reveals a clear picture:
| Category | Weekend % | Pattern |
|---|---|---|
| Automated renewals (30+ days) | 28.6% | No pattern, uniform distribution |
| Late renewals (0-28 days) | 24.95% | Weekday bias (below expected) |
| Expirations | 45.5% | Weekend bias (above expected) |
This creates the "mirror pattern":
- Late renewals happen less often on weekends (25% vs. 29% expected)
- Expirations happen more often on weekends (45% vs. 29% expected)
Understanding the Pattern
Certificate expirations are completely predictable. Unlike sudden infrastructure failures, expiration dates are known as soon as the certificate is issued.
The data shows that automation works in the vast majority of cases. When it does, certificates are renewed uniformly throughout the week, well before expiration.
But when automation fails, certificates enter an "at risk" state. What happens next depends significantly on when the expiration occurs, with weekday expirations being more likely to be resolved than weekend ones.
The pattern suggests that teams often serve as the last line of defense when automated systems fail. During the week, this safety net is somewhat effective. On weekends, it's significantly less so.
The Extended Weekend Effect
Looking at the broader Friday-Sunday window, the pattern becomes even more pronounced:
- Thursday: 7.4% of expirations
- Friday: 20.4% of expirations (3x Thursday)
- Saturday: 34.3% of expirations (nearly 5x Thursday)
The extended weekend (Friday through Sunday) accounts for 65.9% of all certificate expirations.
This progression shows how vulnerability builds as the weekend window approaches and extends.
What This Means
The good news: Most automation works reliably. The 99.5% success rate demonstrates that organizations are largely using automation effectively.
The opportunity for improvement lies in that 0.5% where automation fails. Understanding this pattern helps identify where to focus efforts:
- Automation might be working perfectly, but it's worth testing to be sure
- Monitoring for failures is just as important as monitoring for expirations
- Weekend gaps in human oversight are common and understandable, but they magnify the impact of automation failures
- Earlier thresholds and better failure detection can provide more time to catch and fix issues
How to Improve
Strengthen Your Automation
- Use established tools: Let's Encrypt, cert-manager, or other ACME clients have proven reliability
- Test on weekends: Verify that automation runs successfully during off-hours
- Check dependencies: Ensure DNS, load balancers, and other infrastructure work on weekends
- Review configuration: Misconfigurations are a common cause of renewal failures
Monitor for Failures, Not Just Expirations
Most monitoring focuses on "certificate expires in X days." This is reactive: you only know about problems when you're close to deadline.
Better approach:
- Monitor for failed renewal attempts
- Alert when automation doesn't run as expected
- Track renewal patterns (should happen ~30 days before expiration)
- Get notified when a certificate enters the "late renewal" window
Set Earlier Alert Thresholds
Instead of alerting at 3 days before expiration:
- 28 days: First warning - automation should have renewed by now
- 14 days: Stronger warning - investigate why renewal hasn't happened
- 7 days: Urgent - manual intervention may be needed
Earlier thresholds give you more time to investigate and fix issues, especially important if problems surface on a Friday.
Taking Action
Here are concrete steps to take this week:
Audit your current setup:
- When were your certificates last renewed?
- Was it automated or did someone manually intervene?
- Does your monitoring track renewal attempts or just expiration dates?
Improve your monitoring:
- Set up alerts for failed renewal attempts
- Add 28-day and 14-day expiration warnings
- Consider tools that track renewal patterns, not just expiration dates
Test your automation:
- Verify renewals run successfully on weekends
- Check that all dependencies are available during off-hours
- Review logs for any failed renewal attempts in the past
Resources:
- Tools like haveibeenexpired provide continuous monitoring and track renewal patterns
- Automated discovery can find certificates you didn't know existed
- Monitoring-as-a-service eliminates the need for teams to be the safety net
The Bottom Line
The data shows that:
- Most organizations have working automation (99.5% success rate)
- When automation fails, weekday teams are effective at catching it (75% success)
- Weekend expirations occur at nearly double the expected rate (45% vs 29% expected)
By strengthening automation, monitoring for failures rather than just expirations, and testing during off-hours, this gap can be closed.
Interested in continuous certificate monitoring that tracks renewal patterns and alerts on failures? Check out haveibeenexpired for automated monitoring and host discovery.