Why does "Check Expired Work Items" task run so long?

The 'Check Expired Work Items' task queries for "notifable" objects (workitems and certificationitems) to find any that expire (and either escalate or prune them) or need "waking" (and send a reminder). The "expiration","wakeUpDate" settings hold the values to perform an escalation or notification (msecs since 1/1/1970).

The running time shouldn't be an issue for a background task.  The important status is the successful (or failed) completion.  If there exists business policies/needs to end sooner, then a please contact Support with these requirements.

In general, task execution doesn't suffer from having many WorkItems in the database. If these WorkItems wake up in the same timeframe (ie, same day), then tasks execution takes more time to process all the notices.

To count the objects, run a sql query against SPT_WORK_ITEM table to select id, created, expired and wakeup columns.  Then look for (daily) clusters in expired/wakeup times that the task processes during an execution.

A specific case showed several cluster times with 23.3K workitems:

~15K 8 days ago (Mar15)
~3K 11 days from now (Apr 5)
~5K 19 days from now (Apr 13)

If a task creates 10K certifications, then at least 10K workitems are created.  When a certification has multiple certifiers, then additional workitems appear.  Also, for each certification, even more workitems get created for each revocation on the certification (depending on # of revokers involved)  For example, if one manager revokes 300 accounts spanning 4 applications (that are managed by 4 different revokers), then 4 new revocation workitems appear, each with accounts/entitlement details to each revokers.