I am using postman pro to create a monitor. It is a collection of 25 requests. One of the API throwing ESOCKETTIMEDOUT error. And the same API working fine in the other place when I reused it. Also, it is publicly accessible. Please suggest me something about this.
1 Like
Hi @Dilleswar.tudip! Welcome to our Postman Community 
Did you happen to set a request timeout when creating the monitor? It’s under “Additional Preferences”. If you have one, I’d disable or increase the time specified to see if that makes a difference. Let us know!
1 Like
Thanks for your quick response. I had already tried with this. As per our project requirements, the response time of the request depends on the parameters passed and the parameters are dynamic. If we set request time out it is always failing the test cases.
Hey @Dilleswar.tudip! Just to clarify, you’ve tried the monitor without that box checked and it works sometimes but not others? Or is the collection run working in the Postman Runner (in app) but has never worked when using Postman Monitors, no matter the configuration?
The collection runner in the postman works fine. But in the monitor some times i am facing the ESOCKETTIMEDOUT sometimes. I am trying to track that, but i am unable to find exactly whats happening with the monitor run.
@Dilleswar.tudip Can you clarify if one of your API endpoints is returning the error? Do you face the same error when running the collection on the Postman app?
Another potential reason might be firewalls. If your API is behind a firewall that blocks requests from external hosts, you can get this error. So, if you are on a network that the firewall is supposed to trust, your local Postman app might run the collection successfully, but Monitors will fail, since they run on networks external to the firewall. Can you check this and confirm?
Otherwise, monitors have an upper limit of execution time of 5 minutes, beyond which a monitor run is halted. Though I doubt that is the issue you are facing here. Still it will be good to confirm that.
Thanks for the quick response @kaustavdm
I am facing this issue for only two endpoints in the collection and my collection run time is 3 minutes. It is working fine in my postman collection runner. I am facing this error some times while running in the monitor. If it is the firewall issue, this might have to fail all the time. The endpoints have public access as well.
This looks like an issue with the endpoint your requests are hitting and not something specific to Postman. You should check the performance of that endpoint if you have access to those APIs’ metrices.
On the Postman side, I recommend that you add a test to check for response time on those requests. You can set a test at the collection level and that will run for all requests.
Here is a sample test. Adjust the values to your acceptable limit:
pm.test("Response time is less than 200ms", function () {
pm.expect(pm.response.responseTime).to.be.below(200);
});
You can also find these snippets in the right sidebar of the Tests tab’s editor under each request.
I had also added a test case to check the response time. It will take the minimum to seconds to capture the response. In my case, I had added the time to be below 1000 ms. 30% of the cases I am facing this ESOCKETTIMEDOUT issue.
This definitely looks like an issue with the response time of the endpoint, not something Monitors can handle for you directly. Your options are either to increase the request timeout like @claire had originally mentioned. Or improve the performance of the affected endpoint. Or, ideally, both.
We have improved the performance of the end-point. Now the response time is nearly 1.5 seconds. Still i am facing the same issue while running on the monitor.
@kaustavdm @claire Could there be an issue with once a response time fails then subsequent Monitor runs always report ESOCKETTIMEDOUT regardless of response time? I ask because I experienced the same issue reported here - I have a monitor that runs every 3 hours that had a 3 second response time set. The monitor ran successfully 10 times and then failed at 2am (it looks like the response time was breached). Every successive run after that time failed. I tried the request (which is to a public endpoint) successfully and then watched the monitor fail again. I edited the Monitor, increased the response time to 10 seconds and ran - this time the monitor passed and the response time for the endpoint that previously failed was <1 second. It seems unlikely that the endpoint suddenly responded quicker in the short time it took me to manually trigger a monitor run, watch it fail and me to update the Monitor response timer…
@steve.gibbard Monitor runs are independent of each other. Failure in an earlier run does not affect future runs. Unless, you want to make subsequent runs fail. In that case, you can an environment variable to store the state and use it as an indicator. Say, your scripts has a test for a boolean-ish variable, which if matched, will fail the test.
I don’t have much clue what is going on here, TBH. From the outset, it looks like the endpoint may have sporadic delays. In rarer situations, these may have coincided with a temporary traffic spike in our Monitors infra. You can subscribe to the Postman Status Page to see if there are service downtimes.
Hello, Im facing the same issue as reported above.
The Monitoring execution is configured to run every hour, The API fails with ESOCKETTIMEDOUT error 4-5 times a day and mid night also. There is no firewall blocking, and API is public.
Since We have configured Opsgenie, it’s really troublesome to get false alarms.
Already had a 2000 ms Request Timeout and added a delay in the Pre-requisite step also.
Is there anyway postman team can help me here, will be really really helpful.
And the total time for the collection to run is not more than 2 mins.
