Skip to content

← Blog

60/30/14/7 Slack SSL Alerts for Small Teams

By Nick Phillips, Founder

60/30/14/7 Slack SSL Alerts for Small Teams

Decorative SSL alert title card illustration

Monitor the live certificate served to users, not the one sitting in your renewal script’s logs, and push tiered, low-noise alerts into a dedicated Slack channel through a reviewed app or a properly secured workflow webhook. Each message should carry hostname, issuer, expiry timestamp, days remaining, and a verification link. Anything invalid or failing an HTTPS check needs to escalate immediately, not wait for the next scheduled check.

TL;DR:

  • Monitoring should verify the live certificate served to users, not just the one in logs, and escalate immediately for any invalid or failing HTTPS checks.
  • Checks must include the complete trust chain, hostname matches, alternate hostnames, non-standard ports, and the actual deployment across load balancers and CDNs.
  • Use a reviewed Slack app with proper scope for multiple publishers, or a secure webhook with strict access control, to prevent security risks.
  • Routine warnings should be scheduled at 60, 30, 14, and 7 days before expiry, with immediate escalation for invalid certificates or failed checks.
  • After renewal, re-verify the live endpoint, inspect the chain with tools like OpenSSL and curl, and confirm all endpoints serve the new certificate to prevent silent failures.
Otterwatch
Keep SSL Warnings Calm and Timely
Otterwatch watches your live SSL certificates, sends friendly expiry warnings, and quietly checks that your websites stay up.
Explore Otterwatch

Table of Contents

How Do You Set Up SSL Alerts in Slack Correctly?

Setting up slack ssl alerts that actually catch problems means checking more than the date printed on a certificate. A surprising number of outages happen even though the certificate on file was fine. The gap is between what was issued and what is actually served.

Here’s what a monitoring setup needs to check on every pass:

  • Live endpoint validity — pull the certificate straight off the connection (not from a file or a CA dashboard) and confirm the leaf’s NotAfter date, the SAN list, and that the hostname you’re hitting actually matches what’s on the cert.
  • Full trust chain and issuer — a missing intermediate certificate can break trust in some browsers while looking fine in others, so verify the whole chain, not just the leaf.
  • Alternate hostnames and non-standard ports — WWW versus non-www, API subdomains, and anything running on a port other than 443 all need their own checks, because a monitor that only tests your homepage will miss a stale cert quietly serving on api.yoursite.com.
  • Renewal pipeline health — confirm the renewed certificate actually landed on every load balancer and CDN edge, not just that your ACME client reported success.

That last point trips up more teams than expired certificates do. Cloudflare’s own guidance on this is blunt: alerts should cover issuance, renewal, validation failures, and expiration as a full lifecycle, not just a countdown timer.

Slack App or Webhook: Which Fits Your Team?

You’ve got two real paths for getting SSL error messages into Slack, and the right one depends less on technical preference and more on how many people touch the system.

A native Slack app uses OAuth and defined scopes, which gives you a clean audit trail. If someone leaves the team, you revoke their access without breaking the integration for everyone else.

A workflow webhook is simpler to wire up. You get a request URL, you POST to it, and Slack posts your message. The catch: that URL is a bearer credential. Anyone who has it can trigger the workflow, and Slack’s own security guidance treats webhook URLs as sensitive secrets that need protecting the same way you’d protect an API key.

  • Solo maintainer or single script posting alerts → a webhook is fine, as long as it’s stored as a secret and never committed to a repository.
  • Multiple publishers, shared ownership, or a security review policy → a reviewed app with proper scoping is the safer long-term choice.

Before approving any integration, Slack recommends checking app scopes, posting frequency, and who owns the maintenance before it goes live, not after something breaks.

Pro Tip: If more than one script or service needs to post SSL alerts, route them through a single reviewed app instead of handing out five separate webhook URLs. One credential to rotate beats five to track down when someone leaves.

Slack App or Webhook: Which Fits Your Team? — overview diagram

What Alert Thresholds Actually Prevent Outages?

Certificate lifetimes are shrinking, and CA/Browser Forum ballot changes point toward shorter maximum validity windows going forward. That makes lead time matter more, not less. A single 90-day warning is not a policy. Here’s a threshold schedule that catches problems without burying your team in noise:

  1. 60 days remaining — first heads up, informational tone, dedicated channel.
  2. 30 days remaining — second reminder, still routine but slightly more visible.
  3. 14 days remaining — this one should feel different. Time to confirm the renewal is actually scheduled.
  4. 7 days remaining — final warning before the window gets uncomfortably tight.
  5. Invalid cert or failed HTTPS check — immediate escalation, any time, regardless of the countdown schedule.

Route the routine 60/30/14/7 warnings into a dedicated monitoring channel. Send anything in that last category, invalid certs or failed handshakes, straight to an on-call escalation channel instead. Mixing the two is how real emergencies get scrolled past.

Notification behavior matters as much as the schedule. Fire one alert when a threshold is crossed, not one every single day counting down. Suppress repeats of the same warning, and once the certificate is renewed and verified, post a plain recovery message. A channel that only ever says “expiring soon” and never says “fixed” trains people to ignore it.

What Alert Thresholds Actually Prevent Outages? — overview diagram

How Do You Actually Build This?

Implementation breaks into three pieces: the Slack side, the probe side, and the wiring between them.

  1. Create the Slack workflow or app first. In Slack’s Workflow Builder, set up a workflow that starts from a webhook, then save the request URL it generates. Restrict who can edit that workflow, and treat the URL exactly like a password, because Slack’s own documentation is explicit that anyone holding it can trigger it.
  2. Set up the probe. This can be a monitoring service or a scheduled script. Either way, it needs to fetch the live certificate from each hostname, compute days remaining, check the SAN list and chain, and package the result as structured JSON before posting.
  3. Wire the two together and test both directions. Trigger a warning path and confirm it lands correctly formatted in Slack. Then confirm the recovery message fires after a real or simulated renewal.

Teams without a dedicated monitoring platform often start with something close to a scheduled script. One documented approach reads a list of URLs, pulls the issuer and NotAfter fields, computes days remaining, and posts the result to a Slack webhook on a recurring schedule, no infrastructure beyond a cron job or scheduled task.

The script itself is the easy part. What actually prevents outages is documenting who owns the webhook URL, who rotates it if it leaks, and who’s responsible for confirming the renewal path still works after the next platform update.

Include a direct verification link in every message so whoever reads the alert can confirm the live status in one click instead of trusting the alert blind.

What Should You Check Right After a Renewal?

A renewal that reports success and a renewal that’s actually working are not the same event. After every renewal, run through this before marking it closed:

  • Probe the live endpoint again. Confirm the new NotAfter date, SAN list, issuer, and hostname match on the connection itself, not on a certificate file sitting on disk.
  • Run openssl s_client -connect yourdomain.com:443 -servername yourdomain.com to inspect exactly what’s being served over the wire.
  • Run curl -v https://yourdomain.com and check the handshake output for the certificate chain and hostname validation Curl reports.
  • Re-run your monitoring probe so the same check that raised the original alert confirms the fix.
  • Audit every alternate hostname, CDN edge, and load balancer. This is where old certificates hide the longest. One endpoint quietly serving stale material while everything else looks fine is a common failure mode, and it’s exactly the kind of thing that causes renewal jobs to silently fail on deployment even when the certificate authority confirms issuance.

A Small-Team Checklist for Low-Noise Alerts

Otterwatch was built around a straightforward premise: small teams don’t need dashboards, they need a plain heads up early enough to act on it. That same philosophy scales down into a workflow any team can run without a dedicated ops person watching a screen.

The minimal version looks like this:

  • List every public hostname you’re responsible for, including API subdomains and CDN edges.
  • Apply the 60/30/14/7 day threshold schedule to each one.
  • Route routine warnings to a dedicated Slack channel; escalate invalid certs straight to on-call.
  • Store the webhook URL as a secret, and note who owns it.
  • Test the renewal path once, on purpose, before you actually need it to work.

Pro Tip: Paste this into your runbook now: enumerate hosts, set thresholds, secure the webhook, test the renewal path, verify post-deploy. Five lines, and it covers the failure modes that actually cause outages.

Following author guidance from Nick Phillips, the pattern holds regardless of team size: clarity beats volume. A channel with five calm, correct messages a month beats one drowning in alerts nobody reads anymore.

Slack Is Where You Respond, Not Where You Monitor

Slack should be the place your team reacts to a certificate problem, never the system that decides whether one exists. That distinction gets lost when a renewal script assumes success and posts a cheerful message without checking the live endpoint. An independent probe is the only thing that proves the real state of a certificate.

Assign an actual owner to the webhook credential and to post-renewal verification. Rotation policy and ownership matter more than which tool sends the message.

— Nick Phillips

Where Otterwatch Fits Into This Workflow

Otterwatch is built around the exact checklist above: monitor the live certificate, keep the noise low, and warn you early enough to actually act. Instead of stitching together a probe script, a webhook, and threshold logic yourself, Otterwatch handles the checking and sends plain, friendly alerts before a certificate becomes a problem, with uptime checks running alongside it as the calm bonus rather than the main event.

Otterwatch

The Free plan covers five domains at no cost, no credit card required, so you can see how the alerts read before deciding on anything more. If you outgrow that, the Pro plan is $15 per month and adds deeper monitoring and more integrations. Want to see what a live certificate actually looks like right now, chain and all? Run it through the free SSL certificate checker first and use that same link in your own Slack messages going forward.

Sources

FAQ

How Do I Set Up SSL Alerts in Slack?

Create a Slack workflow or app and save its request URL, then connect an external probe (a monitoring service or scheduled script) that checks the live certificate and posts structured alerts to that URL. Set thresholds like 60, 30, 14, and 7 days remaining, and escalate invalid certificates immediately rather than waiting for the next scheduled check.

Does Slack Have Encrypted Messages?

Slack encrypts data in transit and at rest, but that protects the message content between Slack’s servers and your client, not the source data your alert reports on. A webhook URL used to post SSL alerts is a separate credential that needs its own protection, since anyone holding it can trigger the workflow.

Is Something Wrong With Slack Right Now?

If your SSL alerts stop arriving, check Slack’s own status page before assuming your monitoring failed, since a Slack outage can silently swallow webhook posts. This is exactly why an external probe, rather than Slack itself, needs to be the source of truth for certificate status.

Can My Boss Hear My Slack Huddles?

Huddles are a separate feature from certificate alerting and aren’t relevant to monitoring setups, but the short answer is that huddle audio isn’t recorded by default and access follows your workspace’s admin and permission settings.

Why Did I Stop Getting Certificate Expiration Emails?

Let’s Encrypt ended its automatic expiration reminder emails, which is exactly why independent monitoring that posts to Slack has become the more reliable approach. Relying on a certificate authority’s courtesy email was never a complete strategy, and now it isn’t an option at all.

What Does Otterwatch Cost for SSL Monitoring?

Otterwatch’s Free plan covers up to five domains with no published limit on core alerting and no credit card required. The Pro plan costs $15 per month and adds deeper certificate monitoring and more integrations for teams managing more sites.

Catch the next cert expiry before your users do.

Otterwatch checks your SSL certificates daily and emails you 30 days before they expire. Five sites free.

Start watching →