# Failover API handling

**URL:** <https://discuss.konghq.com/t/failover-api-handling/1341>\
**Category:** Questions\
**Created:** [June 28, 2018, 9:15am UTC](https://discuss.konghq.com/t/failover-api-handling/1341 "2018-06-28T09:15:16Z")\
**Posts on this page:** 1\
**Showing post:** 19

<div class="post-metadata">

**Author:** ![hassanfarid](https://yyz2.discourse-cdn.com/flex036/user_avatar/discuss.konghq.com/hassanfarid/32/2450_2.png) [@hassanfarid](https://discuss.konghq.com/u/hassanfarid)\
**Post date:** [December 23, 2020, 6:02pm UTC](https://discuss.konghq.com/t/failover-api-handling/1341/19 "2020-12-23T18:02:21Z")

</div>

> [@jeremyjpj0916](#):
>
> The closest thing to this in Kong I think would be using upstream+targets and setting your priority on the cache vip to be crazyy high so it takes the brunt of the % of the transactions. But with passive healthchecks + active(to help auto re-neable the primary cache vip when its healthy again) the you can then achieve the 5xx error to trigger that high priority upstream to fail, thus falling over to the failover url app service vip. It won’t be 100% what you want because the failover url will still get called some in general(but imo its close enough to what you want). But its how you could do it without learning to write a more complex plugin(which anything can be achieved with kong plugins but I don’t know how to build it out entirly without playing with code myself). Its an extremely rare use case too I feel like.

This was the solution that worked for me, with a similar requirement for primary and backup service.

the suggested design will only send 1/1000 request to backup server instead of primary, which resonable in my case.

Another useful article was, [Upstreams and failover - #9 by scortopassi](https://discuss.konghq.com/t/upstreams-and-failover/2724/9)

Here are my configurations,

```yaml
_format_version: '1.1'

services:
- name: my-service
  host: my-upstream
  port: 8000
  protocol: http
  retries: 3
  routes:
  - name: my-route
    paths:
    - /

upstreams:
- name: my-upstream
  targets:
  - target: 192.168.3.23:10102
    weight: 1000
  - target: 192.168.3.28:10102
    weight: 1
  healthchecks:
    active:
      concurrency: 2
      healthy:
        http_statuses:
        - 200
        - 302
        interval: 0
        successes: 1
      http_path: /testKong
      timeout: 1
      type: http
      unhealthy:
        http_failures: 3
        http_statuses:
        - 429
        - 404
        - 500
        - 501
        - 502
        - 503
        - 504
        - 505
        interval: 1
        tcp_failures: 3
        timeouts: 3
    passive:
      healthy:
        http_statuses:
        - 200
        - 201
        - 202
        - 203
        - 204
        - 205
        - 206
        - 207
        - 208
        - 226
        - 300
        - 301
        - 302
        - 303
        - 304
        - 305
        - 306
        - 307
        - 308
        successes: 1
      type: http
      unhealthy:
        http_failures: 1
        http_statuses:
        - 429
        - 500
        - 503
        tcp_failures: 1
        timeouts: 1
  slots: 1000

```

---

_[View the full topic](https://discuss.konghq.com/t/failover-api-handling/1341)._