DOI registration and alerts: trace the event before promising a notification

1. Name the notification before diagnosing its absence

A production notification about a metadata submission and a reader alert about a newly discovered article answer different questions. Ask for the service name, alert type, intended recipient and relevant article. A statement that “the DOI alert is missing” leaves the actual event undefined.

Google Scholar describes topic alerts based on matching searches and new additions to Scholar. A Crossref registration result does not establish that Scholar has added the article or that the recipient has received an alert. Record these as separate observations.

Reference: Google Scholar: search help and email alerts

2. Identify the submission route and inspect its result

Crossref's current documentation distinguishes queued submissions through its web deposit form, admin XML upload or HTTPS POST from the OJS plugin and new Metadata Manager paths, which it describes as immediately processed. Notification and log access therefore depend on the route. Consult the documented path actually used; do not wait for an email that this path does not send.

A received submission is not sufficient evidence that every record registered successfully. Inspect the processing outcome for the particular record and retain the submission reference. If a batch contains failures, assign each failed record its own next action rather than describing the entire batch as complete.

Reference: Crossref: submission queue and log

3. Keep a timeline with an evidence column

In the fictional DA18 case, the team uses a queued submission method. All times below are invented UTC observations for a teaching exercise, not expected Crossref turnaround times. The identifier is recorded only as [article identifier]; it is not a DOI to submit or resolve.

On small screens, scroll the table horizontally, or focus it and use the arrow keys.

4. Read what a callback actually announces

Crossref's callback service can notify a member that a submission or query log is available and provide a URL for retrieving it. Receiving that notification does not replace reading the result. A successfully delivered callback can point to a log that reports a metadata failure.

Add notification receipt and log retrieval as separate entries if the organisation uses this service. A callback is not evidence of an author's inbox receipt, a reader alert or search inclusion. This guide does not configure an endpoint or recommend changing an account.

Reference: Crossref: notification callback service

5. Check the link and the discovery service independently

For the link check, compare the destination's article title and identity with the intended record. A page that opens can still be the wrong article. Record the URL, observation time and discrepancy; ask the responsible production editor to examine the record rather than inventing a replacement identifier.

For a Scholar query, retain the exact search and what was observed. Scholar advises using article-title samples when checking coverage and does not guarantee uninterrupted coverage of a source. A missing observation may call for a later check; it is not proof of rejection, and a corrected publisher page does not prove the downstream result has refreshed.

Reference: Google Scholar: search help and email alerts

6. Give the remaining question to the right owner

Send a metadata error to the depositor with the relevant record and log; a wrong destination to the landing-page owner; and an unclear alert to the person who can verify its configuration and recipient observation. Keep private account details out of a public status note.

A useful note states the latest verified event and the next unresolved question. It avoids both “everything is complete” and an unsupported failure diagnosis. The dates in the public article, the registration process and the observed alert may differ; none should silently replace another.

Questions for a practical final check

• Which service and alert type are expected?
• Does the processing log identify this exact record?
• Does the identifier open the intended article?
• Are discovery and recipient receipt separately observed?
• Does each unknown have an owner and a next check?