NDT Certificate Reminder Not Arriving? Troubleshooting Guide

Check the record before checking email

Open the relevant personnel or company record and compare the saved expiry date with the source document. A notification system can only act on the value it has. If the date was mistyped, omitted, or copied from an old credential period, the expected reminder schedule may not match the real evidence.

Confirm that you are looking at the intended record. Similar titles, duplicate entries, or separate company and personnel records can make it easy to review the wrong item. Match the issuer and credential reference as well as the person's name. A reminder associated with one record does not necessarily describe another credential with a similar title.

Do not change a real expiry date merely to force a test email. That can create misleading status information and affect future reminders. If you identify an actual error, correct it from the authoritative evidence and check the saved result. Keep any broader notification test within an approved test process.

Confirm that email reminders are enabled for the account

NDT Connect's expiry email reminders require an explicit opt-in and a verified account email. Account creation and email verification are separate steps. Being able to sign in should not be treated as proof that the address has completed the verification process required for reminders.

Review the available account controls and confirm the intended setting is saved. If the screen indicates that verification is pending, complete the legitimate verification process for your account. Avoid sharing a verification link with colleagues or pasting it into a public support discussion; the link can contain account-specific information.

A company's operational handover should identify which authorized account receives reminders. Do not assume that changing a personnel contact field automatically changes every account communication destination. Check the actual account information and supported settings, and use the platform's normal process for any update.

Understand the scheduled windows

The configured daily reminder windows are 30, 14, 7, 3, and 1 days before the saved expiry, the expiry day, and 1 day after it. Each window is intended to send once. These are product notification intervals, not renewal requirements set by ASNT, AWS, API, or an employer written practice.

A daily process is not an on-demand send button. Entering a record, correcting a date, or enabling reminders does not mean an email must appear immediately. Likewise, a record added after an earlier window has passed should not be assumed to receive a replay of every missed alert. Review the current state and upcoming actions directly.

Use unambiguous dates when calculating the expected window. Record the date you checked and the saved expiry rather than relying on an email subject remembered from a previous period. If there is a discrepancy near a date boundary, include those facts in a support request and ask how the system evaluated the record.

Check the mailbox in a controlled order

Look in the inbox, spam or junk folder, quarantine notices, and any folders created by filtering rules. Search by the platform name and relevant subject terms without assuming the message came at a particular hour. A rule can move a message even when delivery to the account succeeded.

For a company-managed mailbox, ask the authorized email administrator whether a relevant message was quarantined or rejected. Provide the approximate date and recipient account through the approved support process. Do not disable organization-wide filtering or broadly allow unknown senders just to solve one notification issue.

ASNT's digital badge guidance also directs users to check spam and account contact details when its own messages are missing [1]. That is a useful example of separating account and mailbox checks, but NDT Connect reminders and ASNT issuer communications are different systems. Fixing one does not automatically fix the other.

Distinguish a reminder problem from an issuer problem

A platform reminder concerns a date saved in your account. An issuer message may concern an application, credential status, or additional evidence request. The two communications have different senders and purposes. If you expected an issuer decision, check the issuer's official portal or contact route rather than waiting for a date-tracking reminder.

API publishes its application process and describes follow-up for incomplete applications [2]. Use that program's current guidance when an API application needs attention. A certificate manager does not receive every issuer response or submit missing evidence on your behalf. Keep the application status in a separate controlled action list.

If an issuer has renewed a credential but the platform still shows the old date, update the record from the new evidence. Do not interpret an old-date reminder as a statement that the issuer rejected the renewal. Conversely, a distant date entered in the platform is not proof that the issuer has granted a new period.

Investigate duplicate or unexpected reminders

Compare the reminder details with the saved records. You may have two entries for the same credential period, one old record that was not updated, or two genuinely distinct records with similar names. Identify the relationship before deleting anything. A duplicate file and a separate method record are not necessarily the same problem.

Check whether a reminder belongs to a different configured window. Receiving a message at fourteen days and another at seven days is different from receiving two copies for the same record and window. Preserve the message dates and the relevant record reference so support can investigate a specific issue rather than a general impression of too many emails.

If a renewed credential has been re-entered as a second active record, reconcile the records and retain the historical evidence in your controlled archive. Do not erase the old evidence merely to silence reminders. Update the current tracking information based on the source and the application's supported record controls.

Respond safely to suspicious notification messages

Treat an unexpected request for passwords, payment details, or sensitive documents with care. Open the service through a known address rather than relying on an alarming message link. CISA's Secure Our World guidance recommends recognizing phishing, using strong unique passwords, and enabling multifactor authentication where offered [3].

Those security practices apply to the accounts and services that support your recordkeeping. Do not assume that every feature mentioned in general security guidance is available in NDT Connect. Use the controls the relevant service actually provides and follow your organization's account-security process.

A legitimate-looking logo or familiar credential title is not enough to establish the sender. If a message conflicts with what you see in the official account, preserve the details and use the known support route. Avoid forwarding account tokens or personal credential files to an address supplied only in the questionable message.

Prepare a support request that can be investigated

Provide the problem in one sentence, then include the record type, issuer or title, saved expiry, expected reminder window, date checked, verification state, opt-in state, and mailbox checks already completed. Use a record reference where available. Omit passwords, full verification links, and unrelated personal information.

State whether the issue is no message, a late message, an unexpected date, or an apparent duplicate. These are different investigation paths. If the date was corrected recently, describe the correction and when it occurred. Support needs to distinguish a scheduling question from a delivery problem or a data-entry error.

Do not send an entire personnel file unless a specific authorized process requires it. A screenshot can be useful if it shows the relevant status, but remove unrelated personal details and account tokens. Keep the original source certificate in your controlled record system; support generally needs the saved notification facts first.

Use a manual review while the issue is unresolved

Open the inventory and identify the actual next action for the credential. That might be collecting evidence, checking an application response, or asking the responsible reviewer about a date discrepancy. The absence of an email should not stop this work, especially when the date is close.

NDT Connect reminders do not issue credentials, validate scope, or automatically block work dispatch. Employers remain responsible for their qualification and assignment review processes. Maintain a calendar or periodic review that can identify important actions even when a mailbox or notification service is unavailable.

If several people depend on the same record, communicate the factual status through your normal internal process. State the saved date, the evidence being checked, and the next owner. Avoid saying the certificate is fine because no alert arrived or expired because one did; neither conclusion follows from delivery alone.

Check the destination during a team handover

When a coordinator changes, compare the expected recipient with the actual account responsible for reminders. A successor may be checking a shared inbox while the verified account belongs to an individual, or may expect a message that was intended for a different company record. Document the intended ownership and use the supported account process to resolve it. Do not forward private verification links or share passwords to make the handover work. Until the destination is understood, keep the next renewal action visible in the team’s normal review list.

Reconstruct the sequence before assigning a cause

Make a simple event timeline when the basic checks do not explain the missing message. Record when the credential entry was created, when its date was last corrected, when the account became verified if known, when reminders were enabled, and which message was expected. Use observed facts and label uncertain times. A reminder complaint often combines several changes made close together, so investigating only the current screen can hide the conditions that existed when the expected window occurred.

Consider a fictional record whose expiry is twenty days away when the user enables reminders. The earlier thirty-day window has already passed. That sequence is different from a record that was present, correctly dated, verified, and opted in before the thirty-day window. The first case should not assume a missed-window replay. The second may justify a delivery or scheduling investigation. Neither case should be tested by changing the genuine expiry to a convenient date.

Now consider a user who corrects the saved year after receiving an unexpected overdue message. The current record may look correct, while the earlier email accurately reflects the incorrect value stored at that time. Keep the correction date with the support request. Ask whether the observed sequence explains the message rather than insisting that the present screen proves the earlier message was impossible. This allows support to examine the actual chronology without requiring access to unrelated personnel evidence.

Separate observations from conclusions in the timeline. Message found in quarantine is an observation; filtering caused every missing reminder is a broader conclusion that may need more evidence. Likewise, account verified today does not establish that verification was complete last week. A disciplined timeline narrows the problem and prevents repeated setting changes from obscuring the original issue. Keep the renewal action itself progressing while the notification question is investigated.

Give support a small, reproducible case

Choose one affected credential record and one expected window for the initial investigation. State the saved date, the window being discussed, the recipient account context, and the checks completed. If several records appear affected, provide a concise list of their references and explain the common pattern. Avoid sending dozens of screenshots without identifying which one demonstrates the problem. A focused case makes it easier to distinguish one incorrect entry from an account-wide delivery concern.

For apparent duplicates, retain the received messages rather than only a cropped subject line. Relevant details can include receipt times, the referenced credential, and the reminder window described. Share message details through the authorized support route, excluding account secrets and unrelated personal information. Support may request additional delivery information; let the authorized mailbox administrator provide it where appropriate instead of changing organizational mail controls yourself.

Agree on what would count as resolution. Correcting an entry is resolved when the saved values match the reviewed evidence. A mailbox issue may require confirmation from the email administrator. A scheduling issue may need an explanation from platform support. Receipt of a later-window message can be useful evidence, but it does not automatically explain why an earlier message was absent. Record the confirmed cause or retain the case as unexplained rather than choosing whichever explanation seems most convenient.

Finally, close the operational loop. Confirm that someone owns the actual renewal or evidence task, that the current account settings reflect the user's intention, and that the active credential date is supported by its source. Store only the support details useful for future troubleshooting. The outcome should be a dependable next action and an understood notification state, without treating an email investigation as a substitute for the issuer's process or the employer's qualification decision.

Close the investigation with evidence

After a correction or support response, check that the active record contains the intended date and description. Confirm the account's notification settings remain as intended. Do not repeatedly toggle settings or edit the expiry without a reason, as that can make the sequence harder to understand.

Record what resolved the issue: wrong saved date, unverified account, opt-in disabled, mailbox filtering, duplicate record, or another confirmed cause. If the cause remains uncertain, say so. One later email arriving does not necessarily prove which earlier condition prevented delivery.

Update any team handover instructions with the useful lesson. A reminder process works best when everyone understands its boundary: it draws attention to recorded dates, while people maintain the evidence, follow issuer requirements, and decide the appropriate next action. That boundary keeps troubleshooting focused and prevents an email feature from being mistaken for a certification authority.