Automate a weekly domain and SSL expiry watch

A lapsed domain or certificate takes a site offline with no warning. A scheduled agent checks the public dates for each domain weekly and drafts an expiry list its department head reviews and you approve.

What you’ll set up

Connections

Works from public sources: RDAP registration records, Public TLS certificate presented by each site

Inputs

Domains to watch · Required

List, no default

Warning window (days) · Optional

Number, default 30

Ready by · Required

Time, default 08:00

Brief · Required

Text, prefilled and editable during setup.

Runs

Runs every Monday at 08:00

Done by Business analyst

Email to new contacts, and follow-ups nobody has answered, waits for your approval by default. Replies in threads a contact has answered, and email to your own team, can send automatically depending on your settings.

Set up this job

You approve every report · Free to start

How it runs

One agent does the work. Its department head reviews it, then you approve.

  1. 1Business analyst

    Runs every Monday at 08:00 and prepares the report from your connected sources.

  2. 2COO · Review

    The department head reviews the report before it reaches you.

  3. 3You

    Email to new contacts, and follow-ups nobody has answered, waits for your approval by default. Replies in threads a contact has answered, and email to your own team, can send automatically depending on your settings.

What you get

Sample, not live dataSample expiry watch (Sample, not live data)

Sample, not live data. Domains and dates are invented.

Expiry watch, week of 9 Nov (sample)

ItemEndsDays left
shop.example.test certificate2 Dec23
example.test registration14 Feb97
example.invalid registrationnot publishedunknown

Inside your 30-day window: 1 item.

Needs your approval before it is sent.

Two dates, two ways to miss them

A domain registration and a TLS certificate each have an end date, and they are tracked in different places. The registrar emails someone who may have left. An automatic certificate renewal works until a DNS change or a moved server breaks it. Both failures look the same to your customers: the site is unreachable or shows a security warning. The two dates also rarely match: a certificate can end months before or after the registration. A site served from a different host than its domain name may present a certificate issued for that host, so the host that answers is the one that matters.

How the scheduled job works

You list your domains. Each week the scheduled agent looks up the public RDAP record for each one, where the expiration event gives the registration end date, and, where the site answers over HTTPS, reads the notAfter date of the certificate it presents. RDAP is the standard registration lookup protocol, and not every registry publishes an expiration date, so the agent marks those as unknown rather than guessing. If a domain redirects to another host, the agent names the host it checked. It sorts everything by days left and puts items inside your warning window at the top. It reads public data and changes nothing.

Review and approval

Before the list reaches you, the department head agent checks it: does each date come from the record it cites, are unknown dates labelled as unknown, and does a domain that redirects elsewhere get checked at the right host. Then you approve, edit or skip it, and nothing is delivered until you do.

What to do with it

Renew anything inside the window and switch on auto-renew at the registrar where it is off. For a certificate that is near its end despite auto-renew, check the renewal job before the date, not after. Add subdomains that serve customers, since each has its own certificate.

Questions

Start with one report

Set up this job

You approve every report · Free to start