Expiry Notifications
Get alerted by email or SMS before secrets expire.
CIFP can send you an email, an SMS, or both whenever a secret is approaching its expiry date. Notifications are sent per-proxy and are deduped β you will receive each alert exactly once per configured lead time, no matter how many times the scheduler runs.
Notifications currently cover secrets only β API keys, tokens, and passwords added via the Secrets panel. Proxy credentials (the username/password pairs used to authenticate clients connecting to the proxy itself) do not yet trigger expiry notifications, even if given an expiry date.
Configuring Notifications
Open the proxy detail page and click the Notifications tab. From there you can:
- Toggle notifications on or off
- Enter an email address to receive HTML email alerts
- Enter a phone number (E.164 format, e.g.
+15558675309) to receive SMS alerts - Choose one or more lead times β how far ahead of expiry you want to be notified
You need at least one contact method
Notifications are skipped if both email and phone are blank, even when the feature is enabled. You can configure email only, SMS only, or both simultaneously.
Lead Times
A lead time defines how far in advance of expiry a notification is sent. The scheduler checks every hour and fires the appropriate alert as soon as the time-until-expiry drops below each configured threshold.
| Value | Notification fires when⦠|
|---|---|
2w | 14 days or fewer remain |
1w | 7 days or fewer remain |
5d | 5 days or fewer remain |
3d | 3 days or fewer remain |
2d | 2 days or fewer remain |
1d | 1 day or fewer remain |
The default configuration sends two notifications: one at 7 days and a final reminder at 1 day. You can enable as many lead times as you like β each one fires independently and is tracked separately.
How Deduplication Works
Every notification sent is recorded in a local log on the proxy machine. Before sending, the scheduler checks whether the same (item name, lead time, channel) combination has already been sent. If it has, the alert is skipped.
This means:
- A secret with
2wand1dlead times configured will trigger at most two emails and two SMS messages per expiry cycle. - If your proxy restarts or the scheduler runs multiple times in the same window, no duplicate alerts are sent.
- The dedup log is per-proxy and stored locally β it is not synced to the control plane.
What the Notifications Look Like
Email notifications are sent via Resend from the CIFP notification address. The email includes:
- The secret name
- Exact expiry date
- Days remaining (colour-coded: amber β orange β red as expiry approaches)
- A Renew Now button linking directly to your proxy dashboard
The urgency colour escalates automatically:
| Days remaining | Colour |
|---|---|
| More than 3 days | Amber (#f59e0b) |
| 2β3 days | Orange (#f97316) |
| 1 day or less | Red (#ef4444) |
SMS
SMS messages are sent via Twilio and kept intentionally brief:
[CIFP] OPENAI_API_KEY expires in 6 day(s). Renew at https://cifp.vril.devThe message includes the item name, days remaining, and the renewal link. One SMS is sent per item per lead time β the same deduplication rules as email apply.
What Has an Expiry Date?
Only secrets with an explicit expiresAt value set are covered. Secrets with no expiry date never trigger notifications. Set expiresAt when creating or updating a secret via the dashboard or API β see the Secrets guide for details.
Notifications don't auto-renew or auto-delete
CIFP alerts you, but does not automatically rotate or delete expired secrets. After renewing a secret, you should update its expiresAt date (or remove it if the secret no longer expires) to stop repeat alerts.
API Reference
Notification settings are managed through the CIFP API, authenticated with your CIFP API key.
Get notification settings
curl https://cifp.vril.dev/api/proxies/proxy-id/notifications \
-H "Authorization: Bearer cifp_your_api_key"{
"enabled": true,
"email": "you@example.com",
"phone": "+15558675309",
"leadTimes": ["1w", "1d"]
}Update notification settings
curl -X PUT https://cifp.vril.dev/api/proxies/proxy-id/notifications \
-H "Authorization: Bearer cifp_your_api_key" \
-H "Content-Type: application/json" \
-d '{
"enabled": true,
"email": "you@example.com",
"phone": "+15558675309",
"leadTimes": ["2w", "1w", "1d"]
}'No ContentField reference
| Field | Type | Description |
|---|---|---|
enabled | boolean | Master on/off switch. Set to false to silence all alerts. |
email | string | Email address for HTML notifications. Leave blank to disable email. |
phone | string | Phone number in E.164 format (+15551234567). Leave blank to disable SMS. |
leadTimes | string[] | Array of lead time codes. Accepted values: "2w", "1w", "5d", "3d", "2d", "1d". Defaults to ["1w","1d"] if not set. |
Troubleshooting
| Symptom | Likely cause | Fix |
|---|---|---|
| No notifications at all | Notifications are disabled, or neither email nor phone is set | Check the Notifications tab and confirm the toggle is on and at least one contact is filled in |
| Expected alert didn't arrive | Alert was already sent for that (item, lead time, channel) combination | The dedup log prevents resends. If the item has been renewed, update its expiresAt to reset the dedup state for future cycles |
| SMS not received | Phone number not in E.164 format, or Twilio rate limit | Ensure the number starts with + and the country code (e.g. +1 for US). Check proxy logs for Twilio error codes |
| Email not received | Resend API key not configured on the proxy, or landed in spam | Check proxy logs for notify: send email errors. Verify Resend is set up and the from-address domain is verified |