I have a requirement to automatically generate an email with the publishing Status (Success or Failed) of a specific important content item.

This will help us in alerting & troubleshooting in case of a failed publishing status.

We are currently using Tridion 2009SP1.

  • Welcome to Tridion Stack Exchange! I have suggested an edit to your question. If you disagree with the changes please feel free to decline or revert the edit. Mar 16, 2013 at 2:54
  • could someone retag this as this is not about outbound-email Mar 16, 2013 at 8:37
  • @GertjanAssies I removed the outbound-email tag. BTW you have enough rep to retag, it only requires 200 while the site is in beta. Mar 16, 2013 at 16:21
  • @GlennStevens It had a pending edit, that stopped me from re-tagging Mar 18, 2013 at 14:37
  • @GertjanAssies and it was probably my pending edit that stopped you. Sorry about that. Mar 18, 2013 at 15:01

2 Answers 2


This annoys me because of my utmost respect for Chris, but he is unfortunately incorrect. OnPageSetPublishStatus is not fired if your page fails to publish (it is only fired when the publishing status changes - since the failure does not change the last publish date nor the "IsPublished" value, this event wouldn't be fired).

I'm afraid that I have to say that this sounds like a poor man's workaround - if something fails to publish regularly enough for someone to want to get an email whenever it happens, then surely you should address the reasons why it fails to publish, no? A well implemented Tridion system will only fail to publish for valid reasons - like hardware or network failure - and not because it's Friday night or Sunday morning.

Anyway, there's no easy way to monitor this because publishing is a series of processes that happen more-or-less independently.

  1. The item is queued for publishing (OnPagePublish event)
  2. The item is picked up by a publisher machine and resolved (OnPageResolve event)
  3. The item(s) is/are rendered by a publisher (OnPageRender event)
  4. The item(s) is/are Transported to the deployer (no CM-side events anymore)
  5. The item(s) is/are deployed to the delivery side with the execution of whatever deployment pipeline you may be using
  6. The item(s) reports a success status to the CM (OnPageSetPublishedTo event)
  7. Alternatively the item(s) reports a failed status to the CM - no event triggered because there are no data changes to the page

This is how I would implement such a custom monitoring - up to you to disagree with me.

  1. Add a custom resolver that determines if any of the items that needs special attention is part of the current publish transaction. You only mention one "Content File" (whatever that means) for now, but I would expect your requirement to quickly expand to other items you (or your customer) didn't consider yet.
  2. If specialItem is in the list of resolved Items, write to a queue (file system based?) of items to monitor
  3. Separate process - either a job scheduled to run every 5 minutes, or a service with a timer - checks this queue to see if there's any job requiring attention
  4. Job loads the publishing queue to check the status of the item's publish transaction
  5. If that publish transaction is in either failed or success state, notify whomever needs to be notified, modify file queue to state that item is processed and doesn't need additional monitoring

Things to keep in mind:

  • You'll have to use two different APIs to interact with Tridion 2009 at this level. The Custom resolver should use TOM.NET while this "external queue monitoring" process should use the COM-based Tridion Object Model
  • Once you upgrade, this external process should be rewritten to use the CoreService
  • Be prepared to have to start monitoring every transaction instead of just one
  • Resolved items may not show in the queue. If I publish a page with 2 components, the 2 components are Resolved Items - but only the page shows in the queue
  • You can filter the publishing queue by date and Item being published (and a few more parameters) and as said above, the item being published is not necessarily the item you're monitoring.
  • The publisher process may run in multiple machines - but once the resolving is started on one machine, the rest of process is executed by that same machine.

If you have questions about how to implement any of the various things mentioned here, please post them in separate questions.

Last suggestion

Upgrade to Tridion 2011 (or 2013 soon). In 2011 you could use an Event listener on the "Publish Transaction Save" that would give you all the information you need. This is not possible with Tridion 2009.

  • All great points Nuno. I would strongly vouch for upgrading to a system which is less than 4 years old (I.e. at least 2011) Mar 16, 2013 at 13:16

Sounds like you need an event system which listens to the "OnPageSetPublishStatus" event. You event can then check the ID and publish state of the action and send an email.

However, as Nuno clearly states, this will not fire on the failed actions.

In 2009, there is no elegant way to do this. You might consider creating a service that monitors the Publish Q for failed items. Although this is a bit risky as users could delete their failed actions. A combination of that and the above Event will get you most of the way to where you want to be.

  • Thanks everyone for your valuable suggestions and time but I had a bit dificulty in implementing event system as we havent used before. As an alternate approach I set some monitoring scripts to check the publishing error messages from the Tridion Logs and send alerts to the desired mailing group as and when the file fails to publish. And one more alert is created to disable the publishing job whenever the server is down as we do not have the error message logged in case of publishing failure.
    – raniworld
    Mar 28, 2013 at 20:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.