ServiceNow Outage - What happens to our email backlog?

[tcallaghan002]

Evening all,

We are currently refreshing our Service Continuity Plan and a question arose around inbound email in the situation of a Production system outage. We rely on inbound email quite heavily and are wondering what happens to any backlog of inbound emails if the servicenow instance was to go down. Would this backlog be processed once the system is back up? Would email bouncebacks occur? Hope someone can help!

Thanks!

[Dr Atul G- LNG]

Hi @tcallaghan002 

Sharing my thoughts. We had similar discussion (even i am not coder) but what i got that you need to create BR which check and in case any backlog it create the incident. I am good here but i guess it can give you some clue.

[Pius Gumo]

I assume you're referencing the actual receipt of emails rather than the emails being processed. 

In which case, the actual receiving of emails is a managed service by ServiceNow, as such you've offloaded any risk of downtime to them. Reasonably, any large organisation would have in place measures to allow transaction replays, failover data centres, contingency plans and have redundancy to ensure that any email sent to you is actually delivered (Consider that Google has never had a downtime that meant no emails could be delivered). So, to answer your question, there is a 99% chance that the backlog would be processed once the system is backup. And no, email bounce backs would not occur unless all their Data Centres were all on fire at the same time. 

Some technical tidbit about how emails work in ServiceNow. Whenever a customer emails the <name>@service-now.com email address, the mail server receiving this email is not your instance, but a fully-fledged mail server managed by ServiceNow. Your instance will periodically (every 2 minutes OOB) check the ServiceNow mail server for any new email, it will then pull this new email and once pulled, purge it from the ServiceNow mail server. Once the email has landed in your instance, a sys_email record is created for it and business rules trigger (corresponding flows, inbound actions and business rules). Let's consider points of failure from a system architecture point of view.

1. Email sent to ServiceNow address while mail server is down. This is an external risk and ServiceNow have documented practised around how they handle instance and system failures. There is failover and other internal practises that mitigate this risk.
2. Email is not read from ServiceNow mail server as instance is down. Mitigation is that the email will be read once the instance is back up and running. 
3. Email is read and purged from mail servers but not processed in instance. Mitigation is this is within your purview, and you can reprocess emails or setup any other automations means to reprocess the emails at batch.