DOI checking tool?

Hi fellows,

Does any body know about a method to check journal’s DOIs?

DOI plugin (at least in 2.4.5 version) reports that something is submitted, but don’t say nothing about if goes well or not.

Furthermore, urls can change in time (making DOI fail).

As a fast solution, I’m thinking in a bash script taking all the DOIs from and curl-ing against “” to see if response is from domain (fail) or something else (succeed)… but I’m pretty sure somebody else had this need before, isn’t it?


Your DOI registration authority (CrossRef, EZID?) is probably providing (or able to provide) error reports which describe broken DOIs. For example, CrossRef sends a “Resolution Report for prefix” email which describes successful and failed resolution attempts, and their service agreement requires maintaining a low failure rate.

If you have a journal which changes the URL syntax, a best practice is to re-register all DOIs for that journal to ensure the URLs are up-to-date with the registration authority.

Hi Clinton,

Thanks for your fast answer.

We are also working with CrossRef and we get their reports, but…
a) They only list the number of visits of each DOI and the DOIs reported as failure by our visitors. Wrong DOIs (not reported by visitors or enabled at OJS but not submited) are not listed.
b) I don’t want to wait till CR send the monthly report.

I think I will go with the script… With minor changes, this will do the job:

Thanks for your help,

Tested and looks like is working. :wink:

When DOI fails returns a 404 (“Not found”)
Otherwise they return a 303 code (“See other”…) and browser redirects you to the specified url.

Mini howto:

  1. Create a file (call it… “”?) with:

    while read LINE; do
    curl -o /dev/null --silent --head --write-out ‘%{http_code}’ “$LINE
    echo “,$LINE
    done < ./url-list.txt

  2. Create a file with a list of the DOIs you like to check (just DOIs, not the full url). Pe:

    Note: You can get a full list of your journal’s DOIs checking the “article_settings” table in you DB.

  3. Run the script… and you will get the list with the returned code as a prefix, like this:


Redirect the output of this script to a file and you will get a CSV.


1 Like

Thanks, @marc. I am about to use this myself!

Hi @ctgraham… I was happy to help you this time when you are usually the live saver, but about the script, I think it could have side effects. :frowning:

If I understand well how CrossRef (CR) is working, each time “” get an error, is reported to CR, so running this script could increase your monthly report of fails, isn’t it?

It’s not a drama, but taking in consideration how fussy is CR with the “low failure rate” I’m looking for a different approach. Does any body know if there a tool somewhere (, CR…) to make those tests without adding noise the reports?

If we find it, a “check my dois” would be a nice addition to the DOIs plugins.
@bozana, what do you think? :wink:


I imagine the function updateDepositStatus performs a soft check:

Yes it does. :slight_smile:

But the crux of the matter is CR API:

With a registered usr/pwd, you can perform any kind of queries against them.

BTW, did you know about this?


Hi all,

Sorry for late response :frowning:

A lot of CR improvements (also status check) will come with this issue: Improve Crossref statuses · Issue #1498 · pkp/pkp-lib · GitHub. It is actually finished, it just has to be tested once again.
This however considers only CR API i.e. if an URL (or any other metadata) changes, the user is responsible for a new DOI registration i.e. update. If updated, the current status of that last registration attempt will be checked.
There is a slight time difference after the deposit processing completed successfully and DOI being active. If somethings goes wrong in this slot of time, the CR API would show that the DOI is active (the old one, with the old URL), although the second one, with the new URL is still not active. Thus, for this kind of situations (or maybe also to remind the user that an update is needed) it would maybe be good to have an extra check e.g. to check the resolving.
Once we merge the current changes I could take a look at this too…


1 Like