I'm setting up my environment to run the example from lecture #1 (Week01 auction)

All compilations went well but when I try the evaluate in the simulator I always receive:

interpreter Errors
ConnectionError (HttpExceptionRequest Request { host = "localhost" port = 8080 secure = False requestHeaders = [("Accept","application/json;charset=utf-8,application/json"),("Content-Type","application/json;charset=utf-8")] path = "/runghc" queryString = "" method = "POST" proxy = Nothing rawBody = False redirectCount = 10 responseTimeout = ResponseTimeoutDefault requestVersion = HTTP/1.1 } ResponseTimeout)
Please try again or contact support for assistance.

The plutus-playground-server log has the smartcontract and the datum so I think that the call for evaluation was correctly sent but somehow it doesn't come back to the client. In my opinion it's more an issue related to the npm but I don't know how to debug it.

I'm using Ubuntu, all the work done through nix-shell. Plutus tag: 3746610e53654a1167aeb4c6294c6096d16b0502


Further analysis brings me to the conclusion that my system is too slow for the client-server interaction. I saw that the issue is related only to the Auction contract (that's heavier than the demo ones) and watching the trace of the HTTP calls i notice that the /runghc POST takes 34 seconds to give back an answer.

Is there any way i can configure the playground server to consider a timeout higher than 30 secs?

  • Seems strange for it to be a timeout issue (though I'm not an expert) as the server and the client should both be running on your laptop. I followed the steps as shown in Leet Dev's YT channel - is that what you did to?
    – Reddspark
    Commented May 26, 2021 at 0:11

2 Answers 2


You can try configuring the timeout in cardano/plutus/plutus-playground-client/webpack.config.js

devServer: {
    contentBase: path.join(__dirname, "dist"),
    compress: true,
    port: 8009,
    https: true,
    proxy: {
        "/api": {
            target: 'http://localhost:8080'
            timeout: 1000 * 60 * 10
    } },

There also appears to be a proxyTimeout setting that you can try.

I can't reproduce the error on my end so I'm not sure if this will work, but it seems to make sense that the webpack server is timing out.

Here is a general question posted about webpack dev server timeouts that suggest trying the configurations I mentioned above.


  • Unfortunately, it's not a request from the browser to the client app that's timing out, it a request from the server app to a WebGHC instance to compile the code. You won't get away without modifying the source of the server, as outlined in my answer. Commented Oct 13, 2021 at 18:54

This is indeed due to a timeout expiring.

It is not, however, a request sent by the browser timing out, so changing the client Webpack config will not solve the problem as @Frank suggests.

The Plutus Playground server uses WebGHC, served to a different localhost port, to compile the code, and submits the file to the WebGHC instance via a HTTP request. This may take some time to run, and on a slow machine, it can exceed the 30 second timeout.

To fix this, you'll need to dig in to the Haskell source of the playground server.

  • In the Plutus directory, open the file plutus-playground-server/src/Playground/Server.hs in an editor.

  • Change these lines:

    • (around line 29)
      import           Network.HTTP.Client.Conduit  (defaultManagerSettings)
      import           Network.HTTP.Client.Conduit  (defaultManagerSettings, managerResponseTimeout, responseTimeoutMicro)
    • (around line 114)
      manager <- newManager defaultManagerSettings
      manager <- newManager (defaultManagerSettings { managerResponseTimeout = responseTimeoutMicro (1000 * 60 * 1000000) })
  • You'll then need to rebuild the server

    cd /path/to/plutus
    nix-build -A plutus-playground.server

    and then switch back to plutus-playground-client and re-run plutus-playground-server.

This has actually been fixed in more recent versions of the playground (to take a timeout on the command line), but the Pioneer Program is pinned to a specific commit, so won't get the update.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.