SSL Certificate Renewal Workload Calculator for Agencies

Jordan's agency had always treated SSL renewal as background noise. Hosting handled most certificates, calendar reminders caught the odd manual site, and client reports mentioned SSL only when something was close to expiry. Then he counted the portfolio properly: 118 client domains, several CDNs, a handful of vendor-controlled certificates, two old manually renewed certificates, and a future where certificate lifetimes keep shrinking. The problem was not the math alone. The problem was knowing which renewals would need human attention.

An SSL certificate renewal workload calculator estimates how often certificate renewal events happen across a portfolio as lifetimes move from roughly annual renewal to 200-day, 100-day, and 47-day planning horizons. It does not assume every renewal needs manual work. It shows how many opportunities exist for automation, DNS validation, ownership, CAA records, hosting control, or client coordination to fail.

Use this guide to estimate workload, identify where manual processes break, and turn the output into an operational plan. For a direct public readiness check, use 47-Day Renewal Pre-Flight. For the wider monitoring layer, use External Footprint Monitoring and the 47-day SSL readiness guide.

The short answer

Use this simple estimate:

• 398-day certificates create about 1 renewal event per domain per year.
• 200-day certificates create about 2 renewal events per domain per year.
• 100-day certificates create about 4 renewal events per domain per year.
• 47-day certificates create about 8 renewal events per domain per year.

Then separate renewal events from human review workload.

For 25 domains:

• about 25 annual events at 398 days;
• about 50 annual events at 200 days;
• about 100 annual events at 100 days;
• about 200 annual events at 47 days.

For 50 domains:

• about 50 annual events at 398 days;
• about 100 annual events at 200 days;
• about 200 annual events at 100 days;
• about 400 annual events at 47 days.

For 100 domains:

• about 100 annual events at 398 days;
• about 200 annual events at 200 days;
• about 400 annual events at 100 days;
• about 800 annual events at 47 days.

For 250 domains:

• about 250 annual events at 398 days;
• about 500 annual events at 200 days;
• about 1,000 annual events at 100 days;
• about 2,000 annual events at 47 days.

The renewal count is not the same as the workload. The workload is the subset that needs human review, plus the routine needed to notice exceptions before clients do.

Why renewal events are not just dates

A certificate renewal event can be invisible when automation is healthy. It can also turn into urgent support when one dependency is wrong.

The renewal may depend on:

• ACME client configuration;
• HTTP validation paths;
• DNS validation records;
• CAA records;
• nameserver control;
• hosting control;
• CDN configuration;
• client approval;
• vendor access;
• domain ownership clarity;
• renewal ownership and escalation.

The calculator is therefore a risk-multiplier tool, not just a calendar. It answers: "How many times per year could we need to notice and route a certificate exception?"

Calculate human review workload

After estimating renewal events, estimate the percentage that might need review. Even small percentages matter at portfolio scale.

At a 5 percent review rate:

• 25 domains at 47 days create about 10 reviews per year.
• 50 domains at 47 days create about 20 reviews per year.
• 100 domains at 47 days create about 40 reviews per year.
• 250 domains at 47 days create about 100 reviews per year.

At a 10 percent review rate:

• 25 domains at 47 days create about 20 reviews per year.
• 50 domains at 47 days create about 40 reviews per year.
• 100 domains at 47 days create about 80 reviews per year.
• 250 domains at 47 days create about 200 reviews per year.

At a 20 percent review rate:

• 25 domains at 47 days create about 40 reviews per year.
• 50 domains at 47 days create about 80 reviews per year.
• 100 domains at 47 days create about 160 reviews per year.
• 250 domains at 47 days create about 400 reviews per year.

This is where the agency should focus. Reducing the review rate through automation and readiness checks usually matters more than arguing about the exact renewal count.

What changes at 200 days

The 200-day phase reveals whether the agency has a system. A once-a-year certificate process becomes roughly twice per year. That sounds modest until the portfolio includes inherited hosting accounts, old campaign domains, vendor-controlled certificates, and clients who control their own DNS.

Ask:

• Do we know every client domain?
• Do we know the certificate renewal method?
• Do we know who controls DNS?
• Do we know which domains rely on manual renewal?
• Do we know where CAA records could block issuance?
• Do we know what goes into the client report when a certificate is close to expiry?

If those answers are not known, the 200-day horizon is the right time to clean the inventory. The 200-day SSL certificate timeline gives the broader planning sequence.

What changes at 100 days

At 100 days, renewal events become frequent enough that stale spreadsheets start to lie. A manually entered expiry date can be wrong the week after it is typed. A certificate can renew successfully, but the sheet still shows the old date. A new campaign domain can launch without entering the tracking system.

The operational job changes from "remember the expiry" to "monitor the live certificate and route exceptions." The agency should still keep ownership and renewal-method context in a register, but the current status needs to come from a check, not a memory.

What changes at 47 days

At a 47-day planning horizon, the margin for ignored exceptions is small. The agency cannot wait for a quarterly cleanup to discover that a business-critical domain is vendor-controlled, manually renewed, blocked by CAA, or attached to an unknown DNS provider.

The practical response is:

• automate renewal wherever possible;
• independently monitor the live certificate;
• record the renewal owner and method per domain;
• review DNS and CAA readiness;
• group domains by client and business criticality;
• create a clear escalation path;
• include certificate status in recurring domain health reporting.

This is operations, not heroics. The goal is not for humans to touch every renewal. The goal is for humans to see the few that need attention.

Process maturity levels

Use these maturity levels to interpret your calculator result.

Manual tracking means calendar reminders, spreadsheet expiry dates, and ad hoc renewals. It can work for a few domains but becomes risky as frequency grows.

Partly automated tracking means the host, CDN, or ACME client renews most certificates, but the agency does not independently monitor live status. It reduces manual work but still leaves blind spots.

Automated and monitored means renewal happens elsewhere while the agency checks live certificate state, expiry windows, DNS context, and exception status. This is the minimum target for a serious portfolio.

Agency operations workflow means monitoring, ownership, DNS readiness, client grouping, monthly reporting, and escalation are all connected. That is what lets account managers and technical teams explain risk without scrambling.

Sort domains by business risk

Do not treat every domain equally. A main ecommerce domain, support portal, client app, or primary business website deserves a different escalation path than a parked campaign domain.

Use four practical groups.

Critical domains are main websites, ecommerce, booking, login, support, or revenue-sensitive properties. Monitor them closely and report status regularly.

Email-sensitive domains are domains with MX records, authentication records, or business email usage. They need certificate monitoring plus DNS and email-authentication context.

Secondary domains are redirects, campaign names, local-market domains, and brand-protection domains. They still need tracking, but escalation depends on purpose.

Unknown or legacy domains are the inherited rows nobody can explain. These should trigger owner and lifecycle review before the next renewal.

This segmentation turns the calculator from a scary number into a queue.

Build the worksheet

For each client or portfolio, answer:

• How many domains are in scope?
• How many are business-critical?
• How many receive email?
• How many use hosting-managed SSL?
• How many use CDN-managed SSL?
• How many use ACME automation directly?
• How many are manually renewed?
• How many have unknown certificate ownership?
• How many have unknown DNS ownership?
• How many have CAA records that could affect issuance?
• How many are included in client or management reports?

The annual renewal count tells you frequency. The worksheet tells you where the reviews will come from.

What not to include

Keep the calculator focused. Do not mix SSL renewal workload with unrelated service areas.

Do not include uptime monitoring. A certificate can be valid while the site is down, and the site can be up while certificate renewal ownership is unclear.

Do not include page-speed work. Performance is a separate workflow.

Do not include vulnerability scanning or penetration testing. Certificate monitoring is not a vulnerability scan.

Do not include legal compliance conclusions. The calculator estimates operations workload. It does not certify compliance.

Do not include DNS editing or certificate automation claims unless those tools actually perform the work. CertPilot does not issue, install, renew, rotate, or automate certificates.

What to do after calculating

If the number is small, start with public checks and a simple register. Use Pre-Flight before launches, hosting moves, CDN changes, and manual renewals. Use Health Check for single-domain checks when a stakeholder asks about one domain.

If the number is medium, create a recurring review. Group domains by client, capture renewal method, capture DNS owner, check CAA and validation dependencies, and add certificate status to monthly reporting.

If the number is large, build an operations workflow. Assign ownership, define escalation, stop relying on static expiry dates, monitor daily, and document exceptions in reports.

If ownership is unknown, do not wait for the next expiry. Unknown renewal method and unknown DNS control are the two conditions that turn a routine renewal into an incident.

How CertPilot fits

CertPilot helps with the evidence and monitoring layer around SSL renewal work. The 47-Day Renewal Pre-Flight tool checks public signals that affect readiness, including SSL state and several DNS-adjacent signals. External Footprint Monitoring monitors public SSL, DNS, RDAP/domain-expiry, and email-authentication signals and lets teams record governance and SSL-readiness metadata.

The boundaries matter:

• CertPilot does not issue certificates.
• CertPilot does not install certificates.
• CertPilot does not renew or rotate certificates.
• CertPilot does not configure ACME, Certbot, reverse proxies, CDNs, or DNS providers.
• CertPilot does not edit, restore, or roll back DNS.
• CertPilot does not guarantee renewal success.
• CertPilot provides operational evidence and public-signal monitoring, not certification or legal advice.

That is still useful. The renewal system and DNS provider do the technical work. CertPilot helps Jordan know which domains exist, what the public certificate state says, who owns the renewal path, and what needs attention before the client sees a warning.

Worked example: a 120-domain agency portfolio

Suppose an agency manages 120 client domains. Under a rough annual model, that is about 120 renewal events at 398 days, 240 at 200 days, 480 at 100 days, and 960 at 47 days.

Now apply review rates.

If only 5 percent of 47-day events need human review, the agency still handles about 48 review events per year. That is roughly four per month.

If 10 percent need review, the agency handles about 96 review events per year. That is roughly two per week.

If 20 percent need review, the agency handles about 192 review events per year. That is several every week, before launches, migrations, and client escalations are counted.

The lesson is not that 120 domains are impossible. The lesson is that the agency must reduce the review rate and make reviews routable. Unknown ownership is what turns four monthly reviews into a crisis.

Ownership matrix for renewal workload

For each domain, assign the renewal path to one of these ownership patterns.

Host-managed means the hosting provider normally issues or renews the certificate. The agency still monitors live status and records the hosting owner.

CDN-managed means the CDN or edge platform manages the certificate. The agency should know who controls the CDN account and whether DNS validation is required.

ACME-managed means the agency or client operates an ACME client such as Certbot or another automation path. The agency should know where it runs, who maintains it, and what validation method it uses.

Vendor-controlled means a third party owns the renewal path. The agency should record the vendor contact, escalation route, and client owner.

Manual means someone must act before expiry. This should be rare and highlighted.

Unknown means the next action is investigation. Unknown is not a renewal method. It is a risk state.

This ownership matrix is often more useful than the expiry date. Expiry tells you when pressure arrives. Ownership tells you who can remove the pressure.

Client communication after the calculation

Do not send clients a scary raw number. Translate it into the work they care about:

"Your domain portfolio contains 38 monitored domains. Most use hosting-managed SSL. Four domains have unknown renewal ownership, two rely on manual renewal, and three have DNS or CAA context that should be reviewed before the next renewal window. We recommend resolving those nine rows before shorter certificate lifetimes make renewal exceptions more frequent."

That message is useful because it turns the calculator into decisions: identify owner, automate, confirm DNS readiness, or retire the domain.

For agencies, this is also retainer evidence. The client sees why domain inventory, SSL monitoring, and DNS review are operational work rather than background noise.

In short

• Estimate annual renewal events at roughly 1, 2, 4, and 8 events per domain for 398, 200, 100, and 47-day planning horizons.
• Convert renewal count into workload by estimating the percentage that needs human review.
• The dangerous gaps are unknown DNS owner, unknown renewal method, CAA mismatch, vendor-controlled certificates, and missing client context.
• Treat critical, email-sensitive, secondary, and legacy domains differently.
• CertPilot helps monitor public signals and record readiness context; it does not renew certificates or guarantee outcomes.

Frequently Asked Questions

What does an SSL certificate renewal workload calculator estimate?

It estimates how many certificate renewal events a portfolio may create each year as certificate lifetimes shorten, then helps translate those events into likely human review workload.

Why is renewal workload different from renewal count?

Renewal count is the number of expected certificate events. Workload is the human effort required when automation fails, DNS validation breaks, ownership is unclear, a vendor controls renewal, or a client needs an explanation.

Should agencies still keep SSL spreadsheets?

A spreadsheet can help build the first inventory, but it should not be the source of live certificate truth. Live SSL monitoring should verify current status; the register should hold ownership, renewal method, and notes.

Does CertPilot renew certificates?

No. CertPilot does not issue, install, renew, rotate, or automate certificates. It monitors public signals and records operational context so teams can catch exceptions and route work to the right owner.

What is the best first action after calculating workload?

Identify the domains with unknown renewal method, unknown DNS owner, business-critical purpose, active email use, or manual renewal. Those are the rows most likely to create urgent work as renewal frequency increases.