# Curl Timeout Errors

**URL:** <https://discuss.circleci.com/t/curl-timeout-errors/1322>\
**Category:** Build Environment\
**Created:** [December 30, 2015, 7:27pm UTC](https://discuss.circleci.com/t/curl-timeout-errors/1322 "2015-12-30T19:27:55Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![cloudEdwards](https://sea2.discourse-cdn.com/circleci/user_avatar/discuss.circleci.com/cloudedwards/32/665_2.png) [@cloudEdwards](https://discuss.circleci.com/u/cloudEdwards)\
**Post date:** [December 30, 2015, 7:27pm UTC](https://discuss.circleci.com/t/curl-timeout-errors/1322/1 "2015-12-30T19:27:55Z")

</div>

I keep getting intermittent curl timeout errors. There seems to be now rhyme or reason to when it happens.  
Is any one else experiencing this, and does any one have any ideas on how to solve the problem?  
Thanks  
Cloudy

---

<div class="post-metadata">

**Author:** ![levlaz](https://sea2.discourse-cdn.com/circleci/user_avatar/discuss.circleci.com/levlaz/32/36978_2.png) [@levlaz](https://discuss.circleci.com/u/levlaz)\
**Post date:** [December 30, 2015, 10:28pm UTC](https://discuss.circleci.com/t/curl-timeout-errors/1322/2 "2015-12-30T22:28:35Z")

</div>

What are you curling?

There tend to be intermittent network issues with various third party services, registries, repos, etc…

---

<div class="post-metadata">

**Author:** ![cloudEdwards](https://sea2.discourse-cdn.com/circleci/user_avatar/discuss.circleci.com/cloudedwards/32/665_2.png) [@cloudEdwards](https://discuss.circleci.com/u/cloudEdwards)\
**Post date:** [December 30, 2015, 11:55pm UTC](https://discuss.circleci.com/t/curl-timeout-errors/1322/3 "2015-12-30T23:55:25Z")

</div>

Well it often happens with my browser tests that are using curl to access a page in the system, but that can usually be dealt with by making the test wait until the curl get a response.  
In the specific case that brought this up again it was curling  
`curl http://programs.dev/?rs_clear_database_and_seed=true`  
Which is a call to our wordpress that clears and seeds the database.  
If wonder if there is anything we can do about that, or will I have to write a little shell script that retires until the curl passes. We have a script you guys helped us with for a different curl call, maybe that can be repurposed.  
I can’t seem to find it right now, but it was something like this psuedocode.

```bash
curl try-the-url
if the response is not 200
keep trying until it is

```

---

<div class="post-metadata">

**Author:** ![dwenaus](https://sea2.discourse-cdn.com/circleci/user_avatar/discuss.circleci.com/dwenaus/32/532_2.png) [@dwenaus](https://discuss.circleci.com/u/dwenaus)\
**Post date:** [January 5, 2016, 12:14pm UTC](https://discuss.circleci.com/t/curl-timeout-errors/1322/4 "2016-01-05T12:14:23Z")

</div>

the curl we perform is internal, calling the host we define early on in setting up the machine. It fails about 5% of the time. don’t know why.

---

<div class="post-metadata">

**Author:** ![cloudEdwards](https://sea2.discourse-cdn.com/circleci/user_avatar/discuss.circleci.com/cloudedwards/32/665_2.png) [@cloudEdwards](https://discuss.circleci.com/u/cloudEdwards)\
**Post date:** [February 5, 2016, 12:42am UTC](https://discuss.circleci.com/t/curl-timeout-errors/1322/5 "2016-02-05T00:42:56Z")

</div>

Here is the solution that will get these curls to pass.  
This follows the same logic as the psuedo code I wrote in the OP, but it actually works 🙂

`URL=http://your-url.dev RESPONSE=$(curl --write-out "%{http_code}\n" --silent --output /dev/null "$URL") while [$RESPONSE -ne 200] do RESPONSE=$(curl --write-out "%{http_code}\n" --silent --output /dev/null "$URL") done`  
I found that the correct response will probably be 302 if the url is a redirect, so watch out for that

---

<div class="post-metadata">

**Author:** ![system](https://global.discourse-cdn.com/circleci/original/3X/5/1/511608acda8e85906e15909b57bd0a46c1dbe291.png) [@system](https://discuss.circleci.com/u/system)\
**Post date:** [June 18, 2018, 11:37am UTC](https://discuss.circleci.com/t/curl-timeout-errors/1322/6 "2018-06-18T11:37:52Z")

</div>