# Kong error logs create functionality break?

**URL:** <https://discuss.konghq.com/t/kong-error-logs-create-functionality-break/1891>\
**Category:** Questions\
**Created:** [September 17, 2018, 2:32pm UTC](https://discuss.konghq.com/t/kong-error-logs-create-functionality-break/1891 "2018-09-17T14:32:00Z")\
**Posts on this page:** 1\
**Showing post:** 5

<div class="post-metadata">

**Author:** ![thibaultcha](https://yyz2.discourse-cdn.com/flex036/user_avatar/discuss.konghq.com/thibaultcha/32/340_2.png) [@thibaultcha](https://discuss.konghq.com/u/thibaultcha)\
**Post date:** [October 9, 2018, 6:30pm UTC](https://discuss.konghq.com/t/kong-error-logs-create-functionality-break/1891/5 "2018-10-09T18:30:02Z")

</div>

Hi @thiraj89,

Please see this post as a good starting point to debug Kong ↔ upstream connection issues:

> [@104: Connection reset by peer while reading response header from upstream](https://discuss.konghq.com/t/104-connection-reset-by-peer-while-reading-response-header-from-upstream/249/2):
>
> Hi @donalddw, Welcome to the fabulous world of reverse-proxies! “Connection reset by peer” should probably be considered as the initiation rite of any Konger/NGINX user: it isn’t an uncommon error at all. What it means (you might be familiar with it but future readers might not) is that the remote server (your upstream) hung up on Kong and sent an RST packet without bothering doing the usual FIN-ACK handshake. Quite rude. As the error is saying, it seems like the remote is closing its connecti…

An upstream timeout as you noted in your latest post, means that Kong (Nginx here) waited to receive the response headers from _your_ upstream and reached its timeout value (which you can configure on the [Service Object](https://docs.konghq.com/0.14.x/admin-api/#add-service), and is 60s by default). This is most likely an issue with your upstream itself, and not Kong.

---

_[View the full topic](https://discuss.konghq.com/t/kong-error-logs-create-functionality-break/1891)._