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

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: Post-only 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.

Post-only period

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

• Cancel existing open orders
• Create maker-only orders

During this period:

• Market orders and limit orders that cross the order book will be rejected by the trading engine
• Trigger entry, stop loss, and take profit orders will not activate during the post-only period
• Liquidations cannot occur during post-only period, however, if the liquidation threshold is met once trading is enabled, liquidation(s) will occur as documented

This will be employed after downtime while platform checks are being performed. Once the platform checks have been completed, post-only will be removed and trading can resume. The post-only status will be notified via the platform UI, Websocket and REST API notifications as well as on the status page.

Example notification once platform is back online and markets are in post-only mode:

{
"feed":"notifications_auth",
"notifications":[
{
"id":419,"type":"market",
"priority":"high",
"effective_time":1655917620000,
"note":"All contracts are now in post-only mode. Orders can be placed or cancelled, but no trades or liquidations can occur until post-only is disabled."
}
]
}
Example notification once platform is back online and markets are in post-only mode:

{
"feed":"notifications_auth",
"notifications"[
{
"id":420,
"type":"market",
"priority":"high",
"effective_time":1655917620000,
"note":"Post-only mode is now disabled and trading has resumed."
}
]
}