Did you know that Apex callouts continue to execute in read-only mode? Not all developers may be aware of that.
There are a couple situations in which the instance your org is on will end up in read-only mode. One is an instance refresh. Instance refreshes result in periods of read-only mode to facilitate infrastructure upgrades. Another is site switches. Continuous site switching enables Salesforce to improve our operations and infrastructure and meet the compliance requirement of many of our customers. Planned instance refreshes and site switches will put your Salesforce org in read-only mode for a portion of your preferred maintenance windows.
If your Apex callouts perform actions on another system and expects to then do DML in Salesforce, they should be written in a way to handle read-only mode. You can use the Apex System.getApplicationReadWriteMode() method to detect whether your org or the instance hosting it is in read-only mode. In the event either is in read-only mode this method will return an enum value, System.ApplicationReadWriteMode.READ_ONLY.
How does your code handle read-only mode? Take a look to make sure your callouts can handle situations where they are unable to store information in Salesforce after the callout is made.
If you want more information, please please check out these resources:
Chris Peterson is a Lead Software Engineer on the AppExchange team at Salesforce. He is formerly a Force.com MVP and has been building ISV applications on the Force.com platform since 2009. He blogs somewhat irregularly at http://www.ca-peterson.com.
Aaron Slettehaugh is senior director of product management for the Salesforce platform. He has launched several products beloved by Salesforce developers, including custom metadata types and now the Apex Metadata API.