Crypto Facilities is a 24/7 trading platform that strives to reach 100% uptime and connectivity for clients.

However, occasionally, the platform can experience downtime due to planned maintenance and unplanned systems issues.

In order to deal with cases of platform outages, we provide users with a variety of tools to manage the spectrum of downtime that may be experienced:

• Advance Warning: Notification Feed
• Unexpected connection issues: Deadman's Switch
• Returning from downtime: Order Management Period

Notification

Most cases of downtime on the platform occur due to scheduled maintenance. When there is a planned outage, a scheduled notification is sent.

This notification can be retrieved from the Notifications REST API endpoint or received via the Notification Websocket API endpoint.

REST API endpoint Notification

{  
  "result":"success",
  "notifications":[  
   {  
      "type":"general",
      "priority":"low",
      "note":"We've launched a new Telegram group."
    },
    {  
      "type":"settlement",
      "priority":"medium",
      "note":"Week contracts with maturity 29/Jun/2018 expire and settle.",
      "effectiveTime":"2018-06-29T15:00:00Z"
    }
  ],
  "serverTime":"2018-06-29T15:22:05.187Z"
}

WebSocket API endpoint Notification

{
"feed":"notifications_auth",
"notifications":[
{
"id":"The Notification ID",
"type":"maintenance",
"priority":"high",
"note":"A note describing the notification.",
"effective_time":1520288300000
},

...
]
}

When the platform is expected to experience downtime, the notification for both the WebSocket API and the REST API will contain:
type=maintenance
priority=high

The expected start time of the downtime will be in:
effectiveTime
Which represents the unix epoch.

This method will give ample warning time such that you can react programatically.

Additionally, a notification in the UI will pop up to notify users of this, including a popup which makes clear to the user there is downtime coming.

Deadman's Switch

There are other times when perhaps there are connectivity issues or downtime in the network that cause your application to no longer be able to make requests.

To accommodate this, you can use the "cancelallordersafter" REST endpoint to specify a timeout period which, if a new request is not sent before that period, will result in all orders being cancelled.

This can be useful for users who do not want to handle the schedule downtime notifications and would rather let the system cancel all their open orders if the network is down.

Order Management Return Period

This is a period after downtime when the platform has returned, which allows the user to perform only two functions:

• Cancel existing open orders
• Create maker-only orders

This will not always be employed. For example, if there has only been a brief 1-2 minute downtime for a hotfix, and the prices of traded contracts have not moved, then an Order Management Period would not be necessary.

However, if the downtime is for a longer period and the prices of the traded contracts has moved significantly we will, at our discretion, add an Order Management Period.