Chase log: sent, opened or failed, per supplier
If you need to know whether a supplier actually received the certificate reminder you sent, this is the part of Certly that answers it. Every chase email is logged per send against the supplier, showing its status as sent, opened or failed, with a resend action sitting next to the failures.
The reminder you believe went out
You set the reminder, the 90 day threshold came round, the chase went to the supplier contact, and nothing came back. Three weeks later the certificate is inside 30 days and you still hold the same single piece of information: silence.
Silence has at least four causes, and from your side they look identical. The contact left the company and the mailbox now bounces. The address on the supplier record has one wrong character. The supplier's mail server rejected the message. Or the person read it, meant to deal with it, and did not. The first two you can fix in a minute, once you can see them. The third sits with the supplier's own IT. The fourth is a conversation with the supplier. None of those can start while the only thing you hold is an absence of reply.
A spreadsheet column that says "chased 14/03" records your intention, not the outcome. So does a sent folder, which tells you a message left your mailbox and nothing about whether a server accepted it. Certly's chase log is built to separate the two: for each certificate on each supplier, it holds one entry per send, with the status the sending route reported back rather than an assumption that the message arrived.
What the log holds
For every chase email Certly sends, the record carries the recipient address it went to, the time it was sent, the delivery result and any opens. The messages leave through Amazon SES on Certly's own sending role, logged on the way out and honouring the sender's suppression list, unless you connect your own sending account, in which case they leave from your own mailbox, which is what keeps them out of a supplier's spam folder. Either way, the status written against the entry is what that route reported, so you see what was actually sent and what happened to it instead of inferring it from the absence of a reply.
How a chase reaches the log
- The chase sends itself
Certly runs automated chase sequences to the supplier contact for certificates approaching expiry or already lapsed, each message carrying a one click upload link so the supplier can return the document without an account.
- Alert thresholds decide the timing
Expiry tracking works to configurable thresholds at 90, 60 and 30 days before expiry, set per certificate type or as a plant-wide default on the alert settings screen, so the sequence starts while there is still time to get a renewal issued.
- Chase now, when you will not wait for the threshold
A chase now action sits on each supplier row on the dashboard and on the supplier's own page, sending one immediate chase using the same template and writing it into the same history, marked as a manual send so you can tell it apart from the scheduled ones. The automated sequences run on certificates approaching expiry or lapsed, so a document you have never received at all is chased by clicking chase now on that row yourself.
- The message leaves through a logged sender
Chase and upload-link emails go out through Amazon SES on the product's own sending role, where each message is logged and the suppression list is honoured, so an address that has already hard bounced is not fired at again. Connect your own sending account instead and the chase leaves from your mailbox, under your from address.
- Each send is written down
Every send is logged individually against the supplier and the certificate, with the recipient address and the time, so the history reads as a list of events rather than a single last-chased date.
- The delivery result is recorded, not assumed
When the sending route reports a bounce or a failure, that result is written to the chase log and the entry shows its real status, sent, opened or failed, instead of defaulting to sent.
- Failures wear a distinct badge
A failed send is rendered with its own badge in the chase history on the supplier's page, so it reads differently from a send that went out cleanly, and the entry keeps the detail the sending route gave back.
- The address you correct lives on the supplier record
Each supplier row holds its contact details and the certificate types you require from that supplier, so fixing a wrong or dead address is an edit in one place rather than a hunt through a mailbox.
- Resend now sits next to the failure
Each failed entry carries a resend now action, so once you have corrected the contact details on the supplier record you can put the same chase back out from the same screen.
Reading the statuses
| Status on the entry | What it means | What it asks of you |
|---|---|---|
| Sent | The chase was handed off for delivery to the recorded address at the time shown, and nothing has come back to contradict it. Manual sends from chase now are marked as such. | Nothing yet. The sequence continues at the next threshold. |
| Opened | An open was reported back against that send. Open reporting comes from the route the mail went out on, so it appears where that route reports opens and not otherwise. | The ask has reached someone. If the document still does not arrive, the conversation is now with the supplier, not with their mail server. |
| Failed | The sending route reported a bounce or a failure for that send, and the result was written to the log with its own badge and the detail that came back. | Check the contact email on the supplier record, correct it if it is wrong, then use resend now on the failed entry. If the address was already right, the refusal came from the receiving side and resen |
| No entries | No chase has been logged for that certificate. | Treat it as unchased. An empty history is information too, and chase now will start one. |
What the log changes
A dead address stops hiding as a quiet supplier
A bounce you cannot see reads exactly like a supplier who has not got round to it. A failed badge separates the two, so the next action is checking the contact email on the supplier record rather than sending another chase to an address that cannot receive it. Where the address turns out to be correct, the refusal sits on the receiving end, which is also worth knowing before the 30 day threshold arrives.
Whether a chase landed is a question for the log
The per-send history on the supplier's page is the record that carries the status of each individual send. The audit-ready dashboard and its PDF export show each supplier's certificate states for an auditor to read, with the same two-sentence note on both: Certly tracks and reminds, it does not verify a certificate's authenticity or guarantee compliance. When what you need to know is whether one particular chase actually reached someone, read the log rather than inferring it from a date in a column.
Chase history reads per supplier
The log sits on the supplier's own page, next to that supplier's certificates and their required certificate types, so when you open the record you can see what has been asked of them, when, and what came back.
You can read the email before you defend it
The chase settings hold a read-only preview of the exact template that goes out, subject line and body, so you can confirm the message a supplier will receive reads as a plain transactional request with no shortened links.
The trail is kept, not trimmed
Chase history is kept for as long as your account is open, alongside expired certificates, because that trail is what an auditor asks about. Deleting the account removes it all at once.
Where this sits in the rest of Certly
The chase log answers one question: what happened to the emails. The adjoining question, what state each certificate is in across the whole supplier base, is answered on the single screen status view of current, expiring soon, expired and missing, which you can export as a PDF for an auditor to read. The four states have their own page in this section if you want the definitions; the question of whether chase emails land in supplier inboxes at all, and how a QA manager would know, is taken on its own terms on the sibling page about chase email delivery.
That split matters when you are deciding whether a tool like this is worth the switch. A tracker that only shows statuses leaves you guessing about your own follow-up. A mailbox full of sent reminders leaves you guessing about statuses. If you are weighing the options at that level, the sibling pages here compare four ways of tracking expiry dates honestly, including the spreadsheet you are probably running now, and set out what certificate tracking software looks like from a QA manager's desk.
Certly is in build and taking names on the waitlist, so what is written here is what the product is made to do, not a customer story. If chasing suppliers for their certs is an afternoon of your week, the chase log is the part worth asking us about first.
Questions
Can I see whether a supplier received the certificate reminder email?
You can see what the sending route reported for each send. Every chase email is logged per send in the chase history on the supplier's own page, with its status, sent, opened or failed, and a bounce or delivery failure is written to the log and shown with a distinct badge rather than being recorded as sent.
What exactly is stored against each chase?
The recipient address, the time it was sent, the delivery result and any opens. That is held so you can see what was actually sent and delivered instead of assuming it.
What do I do when a chase fails?
Check the contact email on the supplier record, which holds each supplier's contact details and required certificate types, correct it if it is wrong, then use the resend now action next to the failed entry. If the address was already correct, the refusal is on the receiving end and resending the same message is unlikely to change it, so take it up with the supplier directly.
Does a failed send get retried at that threshold?
Not on its own, and we would rather say so plainly. The failed entry stays in the log with its badge, and recovery is a deliberate click on resend now once you have checked the address, rather than something the sequence quietly handles for you.
Which service sends the chase emails, and can they come from our own address?
By default they go out through Amazon SES on the product's own sending role, where each message is logged and the suppression list is honoured. You can instead connect your own sending account, with its from address, mail server, sign-in name and mailbox password or API key stored encrypted, so chases leave from your own mailbox.
Can I send a chase immediately, outside the 90, 60 and 30 day thresholds?
Yes. A chase now action on the supplier row on the dashboard and on the supplier's page sends one immediate chase using the same template, and it is written into the same chase history marked as a manual send. It is also how you chase a certificate you have never received, since the automated sequences run on certificates approaching expiry or lapsed.
Does an opened chase mean the certificate is sorted?
No. An open means an open was reported for that send. The certificate only changes state when the document is uploaded with its expiry date, either by your QA team or by the supplier through the one click upload link in the chase email.
What happens if a supplier contact asks us to erase their details?
A supplier contact's name and email can be erased on their own from the supplier's page, behind a confirmation that explains what is removed, the contact name and email, and what remains, the certificate records. That is the scope of the action today: it clears the contact fields and leaves the certificates in place.