Hermetry records every delivery attempt of its channels in a delivery log: one row per recipient and channel. The log answers “was it sent, to whom, through which provider, and did the provider accept it?”. It complements the usage counters, which answer “how many”.
What is recorded
| Field | Meaning |
|---|---|
| Channel | mail, sms, push, or a chat platform. The bell is not logged: its feed is the record. |
| Recipient | The address, number or member. Stored encrypted with your organisation’s data key. |
| Provider | The mail, SMS or chat provider used |
| Status | sent, failed or pending |
| Subject | For mail |
| Provider message id | The provider’s reference, when it gives one |
| Error | The provider’s error text for a failed attempt |
| Time | When the attempt was made |
sent means the provider accepted the message. Whether it then reached the inbox or phone is up to the provider; bounces reported later are handled separately from this log.
Where to see delivery evidence
In this release the log has no page of its own in the app. Use:
| Where | Shows |
|---|---|
| The alarm’s timeline | Notified with the number of recipients, the channels and whether it was sent as critical; Notification held back (throttle); Muted: nobody was notified. See Working with alarms. |
| A rule’s History | Each run’s steps, including a failed Tell people step. |
| A flow’s debug panel and run results | The Notify block’s msg.metadata.notify counts: delivered, failed, suppressed, invalid, quota, held. |
| Your organisation’s data export | The collection Notification log: what was sent to whom, and when. See Export your data and close your organisation. |
How long it is kept
| Age | What happens |
|---|---|
| Up to 90 days | Kept in full. |
| After 90 days | Anonymised: the recipient, its search index, the subject and the error text are removed. |
| After two years | Deleted. |
A daily sweep applies this to every organisation. The retention is the same for every organisation.
Failure-rate alert
Every 15 minutes Hermetry checks the last 30 minutes of your organisation’s deliveries. If there were at least 20 attempts and half or more failed, the webhook event notification.failure_rate_high (“Notification failure rate high”) is sent, at most once per hour. Subscribe a webhook to it to learn quickly that a mail server, SMS provider or chat platform is failing. See Webhooks.
Typical causes: expired SMTP credentials, a spent provider balance, a disconnected chat platform, a provider outage.
What is not in the log
- Notifications that were never attempted on a channel: held back by a preference, quiet hours, the repeat window, the cooldown or a mute, or with no address for that channel. Those decisions show on the alarm timeline or in the block’s result instead.
- Webhooks: they have their own delivery log. See Webhooks.