To help keep our systems humming along, we need to perform some proactive maintenance on our existing infrastructure.
What are we doing?
This work is primarily preventative maintenance on our database software to apply the latest features and security patches. We need to make sure we stay up-to-date with the current technologies to help keep our service robust and healthy.
When are we doing it?
We're going to begin these changes early in the new year, starting with customers in the European regions (EMEA), before moving on to clients in the Asia-Pacific (APJ) region, and then finishing up with everyone in North America (NA).
Here are the currently planned windows for this maintenance:
|EMEA||January 22-24, 2018||January 29-31, 2018|
|APJ||February 13-14, 2018||February 14-15, 2018|
|NA||February 19, 2018||February 20-22 & 26-28, 2018|
Can we narrow it down a bit?
We will be contacting each of our customers well in advance of this change to provide you with an 8-hour period for one of the dates listed above, during which we will perform the necessary updates.
How will this affect you?
Database updates will require a brief downtime in the xMatters On-Demand service. In addition, we'll want to make sure that nothing is attempting to modify the database during the window - we don't want anything to be half-way through its processing when the updates are applied!
In light of this, please note the following:
- Four hours before the start of your maintenance window, we will pause all EPIC synchronization, user upload, and archive/purge processes.
- During the maintenance window, you may experience up to a maximum of 30 minutes where the service is unavailable. (Most customers will experience significantly less.)
- During this time, notification and response processing is not guaranteed.
What will happen to your events?
If an event enters the system during that brief moment your database is offline for maintenance, one of two things will happen:
- If it comes in through a legacy integration (using an APXML request via the Integration Agent), the event will simply be placed in the queue until the heartbeat between the Integration Agent and xMatters is restored. When the connection is reestablished, the Integration Agent will submit the events in the same order as they entered the system.
- If it's an Integration Agent event targeting a communication plan via REST, the request will return a 503 error (see example below) that we've set up specifically for this maintenance, instructing it to retry every ten minutes, up to three times. If another event enters the system after this, xMatters will place it in the queue for processing behind the first event, and then process them in order once the retry is successful. (This does mean that xMatters might not process the original event immediately when the service comes back online, depending on the exact timing between the 503 error, the retry interval, and the restoration of the service.)
How do you get help?
If you have any questions about this maintenance, use our online form to submit a request to xMatters Client Assistance.