Heroku Error H13

Question

I've been getting this error now on & off for the past couple days since I deployed my application to heroku. It happens both before I started using unicorn as a server as well as afterwards. I can sometimes get it back up and running by using heroku run rake db:migrate then heroku restart but this only fixes it for a couple hours and it's broken again. As for the webpage it's saying "Application error". The logs aren't very helpful but here's what it says each time this error happens:

[2014-10-27T21:13:31.675956 #2] ERROR -- : worker=1 PID:8 timeout (16s > 15s), killing
[2014-10-27T21:13:31.731646 #14]  INFO -- : worker=1 ready
[2014-10-27T21:13:31.694690 #2] ERROR -- : reaped #<Process::Status: pid 8 SIGKILL (signal 9)> worker=1
at=error code=H13 desc="Connection closed without response" method=GET

I'm just using the free version of heroku, I want to make sure it works before upgrading but is that my only option at this point?

Also I am able to run this locally perfectly fine using either rails server or foreman start.

Answer 1

Heroku docs say this about H13:

H13 - Connection closed without response

This error is thrown when a process in your web dyno accepts a connection, but then closes the socket without writing anything to it.

One example where this might happen is when a Unicorn web server is configured with a timeout shorter than 30s and a request has not been processed by a worker before the timeout happens. In this case, Unicorn closes the connection before any data is written, resulting in an H13.

A couple lines up, you have an error about a process timing out after 15s:

ERROR -- : worker=1 PID:8 timeout (16s > 15s), killing   

Heroku help has a section on timeout settings:

Depending on your language you may be able to set a timeout on the app server level. One example is Ruby’s Unicorn. In Unicorn you can set a timeout in config/unicorn.rb like this:

timeout 15

The timer will begin once Unicorn starts processing the request, if 15 seconds pass, then the master process will send a SIGKILL to the worker but no exception will be raised.

That matches the error messages in your log. I'd look into it.