# Smart client handoffs

```json metadata
{
  "title": "Smart client handoffs",
  "description": "Learn how to avoid disruptions during Redis server maintenance.",
  "categories": ["docs","develop","stack","oss","rs","rc","oss","kubernetes","clients"],
  "topics": ["smart-client-handoffs","resilience"],
  "relatedPages": ["/develop/clients/redis-py/connect#connect-using-smart-client-handoffs-sch","/develop/clients/nodejs/connect#connect-using-smart-client-handoffs-sch","/develop/clients/lettuce/connect#connect-using-smart-client-handoffs-sch","/develop/clients/go/connect#connect-using-smart-client-handoffs-sch"],
  "scope": "overview",
  "tableOfContents": {"sections":[{"id":"enable-sch","title":"Enable SCH"}]}
}
```














*Smart client handoffs (SCH)* is a feature of Redis Cloud and
Redis Enterprise servers that lets them actively notify clients
about planned server maintenance shortly before it happens. This
lets a client reconnect or otherwise respond gracefully without significant
interruptions in service.

SCH is primarily useful when server software or hardware upgrades
are required. It provides two main features to help the
client avoid disruptions in service during the maintenance period:

-   **Relaxed timeouts**: Upgrades tend to impact the general performance of the server.
    Advance notification of the upgrade lets a client adjust its command
    timeouts to take this into account and avoid aborting commands too soon.
-   **Transparent reconnection**: Upgrades also involve migrating
    Redis shards to new nodes, which inevitably disconnects clients from
    existing nodes. However, with some advance warning of the disconnection,
    a client can buffer commands, connect to a new node, and then resume
    the buffered commands without aborting any of them. As a result, users
    see no disruption in service.

SCH does not work with blocking connections.
These include connections used for blocking operations like
[`BLPOP`](https://redis.io/docs/latest/commands/blpop) and also
[pub/sub](https://redis.io/docs/latest/develop/pubsub) subscriptions.
All non-blocking operations are safe to use with SCH.


## Enable SCH

SCH is enabled by default on Redis Cloud, but you must enable it
explicitly on Redis Enterprise servers by using the
[v1/cluster](https://redis.io/docs/latest/operate/rs/references/rest-api/requests/cluster)
REST API request to set the `client_maint_notifications` option to `true`.
The example below shows how to do this using the
[`curl`](https://curl.se/) command line utility:

```bash
curl -k -X PUT -H "accept: application/json" \
    -H "content-type: application/json" \
    -u "test@redis.com:test123" \
    -d '{ "client_maint_notifications": true }' \
    https://localhost:9443/v1/cluster
```

SCH is not supported for
[Kubernetes](https://redis.io/docs/latest/operate/kubernetes) clusters
and is supported on Redis Enterprise only for
[rolling upgrades](https://redis.io/docs/latest/operate/rs/installing-upgrading/upgrading/upgrade-cluster#rolling-upgrade).


SCH is enabled automatically on the client side during connection
if you select the [RESP3](https://redis.io/docs/latest/develop/reference/protocol-spec#resp-versions)
protocol, which is a requirement for SCH. However, you can
configure some parameters, such as the timeouts to use
during maintenance.
See the pages linked below to learn how to configure SCH for:

- [redis-py](https://redis.io/docs/latest/develop/clients/redis-py/connect#connect-using-smart-client-handoffs-sch)
- [node-redis](https://redis.io/docs/latest/develop/clients/nodejs/connect#connect-using-smart-client-handoffs-sch)
- [Lettuce](https://redis.io/docs/latest/develop/clients/lettuce/connect#connect-using-smart-client-handoffs-sch)
- [go-redis](https://redis.io/docs/latest/develop/clients/go/connect#connect-using-smart-client-handoffs-sch)