Skip to main content
Version: 0.17

Digests and endpoint health alerts

Use a weekly digest for a consolidated expiry summary, or enable endpoint health checks for outage and recovery notifications. Both use workspace delivery windows and channels. Individual expiry reminders are covered in Expiry reminders and thresholds.

Weekly digest​

The weekly digest sends a summary of all tokens close to expiring (within your thresholds) once per week per contact group, giving you a consolidated view instead of individual alerts for each token.

  • Enable per group: in contact group settings, check "Email weekly digest", "WhatsApp weekly digest", or "Webhook weekly digest".
  • Frequency: sent once per week (on Mondays) per contact group. If that Monday run falls outside your delivery window, it is skipped (not deferred).
  • Token selection: uses the largest workspace threshold that is ≥ 1 (not a union of group-override thresholds). For example, if workspace thresholds are 1, 7, 30, 60 days, the digest shows tokens expiring in 60 days or less. Excludes already expired tokens.
  • Channels: email, WhatsApp, and webhooks (Slack, Discord, Teams, generic). PagerDuty is not supported for digests.

Endpoint health alerts​

When you add an endpoint monitor with health checking enabled, TokenTimer tracks the health status of that URL and alerts you when it goes down or recovers. Alerts are triggered on state transitions only, not on every check.

How it works​

  • First check: the very first health check establishes a baseline. No alert is sent regardless of the result.
  • Healthy to unhealthy: when an endpoint transitions from healthy to unhealthy (HTTP error, timeout), a "down" alert is queued.
  • Unhealthy to healthy: when an endpoint recovers, a "recovered" alert is sent, but only if you were previously notified it was down.
  • No change: if the status stays the same between checks, no new alert is created.

Alert after failures​

To avoid false alarms from brief network glitches, you can configure how many consecutive failures must occur before you are notified. This is the "Alert after failures" setting on each endpoint.

  • Default is 2 consecutive failures.
  • The "down" alert is queued immediately on the first failure transition, but the delivery worker waits until the failure count reaches the threshold before sending the notification.
  • If the endpoint recovers before the threshold is reached, the queued alert is silently discarded and you receive nothing.
  • Recovery alerts have no consecutive-failure gate, but still respect the delivery window. They are sent only if a "down" notification was previously delivered.

One notification per state change​

  • Only one "down" alert is sent per outage, no matter how long the endpoint stays unhealthy.
  • Only one "recovered" alert is sent when the endpoint comes back online.
  • If an endpoint was never healthy (for example a misconfigured URL), the first check produces no baseline transition. A "down" alert fires only after it eventually becomes healthy and then goes unhealthy again.
  • Recovery alerts are never sent if you were not previously informed of the outage.

Delivery channels and contact groups​

Endpoint health alerts use the same delivery channels configured in your workspace alert settings and respect your delivery window.

  • When adding an endpoint, you can select contact groups to receive alerts. This is set on the auto-created SSL token.
  • If none are selected, the workspace default contact group is used automatically.
  • You can change the assigned groups later by editing the SSL token directly.