Iāve not checked it out properly, but if youāre on Mac, someone at my company suggested RapidAPI for Mac instead.
1 Like
The really funny thing about this is that support have confirmed to me that the 250 runs on professional is counted for the entire team not per user.
Weād actually be better off going back to the free plan so we get 25 runs per user.
The message from Postman is very clear: Upgrade to Enterprise or go away. Weāll do the latter.
10 Likes
@docking-module-part1 Postman CLI runs arenāt affected by this limit. Theyāll count against the ācalls to the Postman APIā quota (see pricing page).
@norrispostman As far as Iām aware the limit on the free plan is also per team, as long as youāre in a team.
@ign-cloudferro Have you looked at running your collection as a scheduled run or using the Postman CLI or Newman? Sounds like you may benefit from it instead of running a collection that big manually every time.
2 Likes
Hi,
I am Product Manager with Postman and I was going through this thread.
@norrispostman Please send us more details at help@postman.com so we can understand your situation better and support you. Our goal is to enable your workflows as seamlessly as possible while you get time to respond to the change. If you wish to discuss this instead, please use this calendly link to schedule some time with me. We would like to understand your current workflows and how you use Runner.
The changes will be effective on March 15 if you are on our basic/professional plan and on Feb 15th if you are on the free plan (the limit will be effective post your plan renewal happens i.e. existing plans or plans purchased before March 15th will have unlimited runs until their renewal date)
@jon.krantz Please send us a mail at help@postman.com so we can help you get unblocked for your release and while you get time to respond to the changes.
Hi @ign-cloudferro Please use this calendly link to schedule some time with me. We would want to talk to you and understand how we can help you. I understand that 25 runs limit might be affecting your workflows suddenly and we want to make sure we unblock you so you can understand these changes better.
I feel that this new limit makes little sense and only hurts this amazing Postman community. It can also deter others from adopting Postman in the first place.
Anyone using Postman with the intention of automating runs knows that using the Collection runner is the first tool that is being used to test if an automated collection run is possible (setNextRequest, external data files, variables, etc.).
It is also the most helpful tool for debugging a collection that fails to work. Since it is integrated into Postman, it makes inspecting the requests/responses/console much easier compared to Newman or any other tools. It is an important productivity tool.
Anyone who has used the Collection Runner to prepare a collection for automatic runs can easily understand that 25 runs can be consumed even in an hour of testing. So the limit of 25 collection runs essentially kills the usefulness of this tool. What can be more frustrating that having to stop work because you have hit an artificial limit? Even 250 runs on the professional plan is very very little.
To properly do automation, the Collection Runner is key. For a team, hundreds, if not thousands, of runs are needed. How can people see the value in paying for more advanced features if they canāt even get something simple to run? If somebody canāt automate a collection run locally, I doubt they will spend the time to use a CLI tool.
This limit of 25 collection runs is completely misaligned with other limits that the free tier has, like 1000 API calls.
Since this feature does not seem to use any Postman cloud resources, it also seems unfair. What is the justification for this change? The jump from unlimited usage to 25 runs is way too sudden and just hurts Postman as a test automation tool.
I understand that Postman needs to earn money to keep the product and the development efforts going. Postman has grown a lot over the years. We all want a financially stable company to take care of the product.
At the same time, the productās users need to see the value in paying for the product. From this thread, it seems that many already paying customers no longer see the value, which is very sad.
28 Likes
@supply-administrato3 When you say āexisting plans or plans purchased before March 15th will have unlimited runs until their renewal dateāā¦is this ārenewal dateā when we play the next monthly invoice (we are on the monthly basic plan)? Which isnāt really a renewal, just paying a bill. So until we cancel or change plans, will we continue to have unlimited Collection runner runs?
Completely agree with you, this unfair change is indeed disgusting to users, it takes away its basic productivity, infact before this change I was going to upgrade to a paid plan, but now it seems unnecessary, perhaps that is the value of who made the limit, Iām also sure @supply-administrato3 wonāt say here the justification in which made this change, right?
Only the valueeeeeeeeeeeeeeeeā¦
4 Likes
Correct, i am in the same boat. I purchased an annual Professional plan which expires in August.
I assume this will be walked back a good bit or Postman risk seriously hurting their (good) reputation.
5 Likes
We all hope so, but as engineers we have to work with worst case scenario. So i have until August to find alternatives and migrate.
Thank you all for your feedback. A majority of our customers chose the Enterprise plan to run and deploy quality and security gates through a combination of manual and automated tests. We set plan thresholds in a way so customers only upgrade when they find value in the product. We understand that some of our customers might have use cases that cross those thresholds but also donāt find enough value to upgrade. Please get in touch ,at help@postman.com, with us so we can understand your use case better
āWe understand that some of our customers might have use cases that cross those thresholds but also donāt find enough value to upgradeā.
Well, let me translate it, āAll you guys should upgrade to the not enough value enterprise planā, thatās the value.
2 Likes
The use case is literally to just run things locally.
Your limitation on local runs makes no sense. Any other limitation would make sense, like Postman API calls or Storage usage.
This is a bullshit response and you know it.
6 Likes
@docking-module-part1 I found something interesting, Postman is collecting data on the runnerās runs, via
{
"service": "usage",
"method": "get",
"path": "/usage/operations/collection_run_limit"
}
{
"operation": {
"allowed": false,
"limit": 25,
"remaining": 0,
"usage": 25,
"overage": 0,
"spillage": 99999999,
"allowOverage": false
}
}
It is not known when this collector was added,
therefore, @supply-administrato3 @preetham.m it is not possible for Postman to be unaware of the user case, instead itās possible that Postman has collected a lot of this operational data to make this limit for users.
Another question is why still send tracking data to these servers even if this option āSend anonymous usage data to Postmanā was turned off?
for these trackers?
analytics.getpostman.com
bam.nr-data.net
insights-collector.newrelic.com
js-agent.newrelic.com
o1224273.ingest.sentry.io
After doing some research, I was also concerned about what it says about data security.
4 Likes
What is emailing help@postman.com going to achieve?
You know what the use case is for the runner. Itās your product, you designed it.
If you are in doubt. Your product has some key elements that only work in the runner. The ones that are useful for automated testing, including setNextRequest and data driven tests.
This runs locally using the Postman desktop client, and until recently had no limits.
Youāve imposed a hard to understand limit, which makes the feature nearly unusable for everyone outside of an Enterprise plan. Even the professional plan limits look artificially low as its based on the team.
For pretty much everyone here, it would appear that you have done this solely to push the more expensive Enterprise plans. If you havenāt, then it would be nice to hear the rationale behind this move.
As mentioned previously, if a company is willing to pull or severely limit a feature that has been free for over a decade, then what other feature may you restrict in the future? (For example, pulling the support for Newman over the CLI, or perhaps sendRequest() next.
sendRequest uses no local resources, just like the Collection Runner, so Iām guessing its fair game.
The main issue here is a loss of trust.
Iāve only been using the product for six months, and was starting to get colleagues within my organisation to invest time to see if we should adopt more globally. We were using the free version and sticking the code in our code repository which was all we needed for our current requirements as we donāt design many APIās, we just consume others so I donāt need the documentation features.
There is always a risk in using free software, that it will be pulled or deprecated and that is always the risk you take.
However, now knowing that Postman appear to be in this camp. I cannot realistically continue to champion the product internally as I no longer know if key features may be removed or limited in the future.
This probably means we will now look for paid for software, but I doubt I would recommend Postman as an option because of what has happened here.
Enterprise is too expensive for our use case. Making you more expensive than SoapUI.
Adding new features to the top tier like your new CLI to streamline integration. That would be fine. But removing or severely limiting existing features is not a business practice that I can recommend.
13 Likes
Interestingā¦maybe we could figure out how to block that traffic from going out so that we dont hit the limit?
1 Like
@docking-module-part1 We can indeed do this with some hacking tricks, but hopefully Postman can design reasonable and competitive subscription plans instead of playing tricks.
@supply-administrato3 the only product manager on the community, right?
2 Likes
@preetham.m This is an infuriating response. You have a lot of people right here trying to communicate their use case right here, can you please respond transparently?
Can we have a direct response as to the justification why there is a limit on using local resources?
Every day that goes by with more doublespeak erodes the trust that you have built up over the years. Postman used to be a no-brainer, but this boneheaded move is really transparently greedy and disappointing.
6 Likes