@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
Respectfully, this smacks of driving users to your expensive enterprise plan.
I can understand why you would restrict runs on a free tier, you are running a business after all , but given that this is a restriction includes localhost runs, and runs on restricted environments, it feels stingy.
250 runs for a Ā£36 per user per month is very steep. I only use Postman for QA of my companyās APIs. I could easily hit 1000 runs a month when Iām busy, probably more than that. My work covers exploratory testing, field assertions and end to end regression testing. Itās 3600/250 = 14.4p per run. If I want to generate Bearer Tokens, thatās 14p. If I want to validate a change, using a regression pack, thatās another 14p.
I pay for pro tier as I understand the need to support the developers of the tools that I use. I also understand why you would have a higher level of cost for users hitting 100k runs per month, but Iām going to have to look elsewhere. Itās a shame but I just canāt justify the cost if the restriction is to remain that severe.
7 Likes
Youāve copied the same words on GitHub.
Letās keep track of this issue.
4 Likes
Just encountered this myself - these limits seem crazily low and pretty much make the product unusable for me.
If someone had typoed āMonthā instead of āDayā I could understand it, but even then 250 runs in a day would be quite limiting if you were developing a collection of tests.
As the counter increases every time you hit the button, if youāre writing a new scenario with some pre-request scripts that need debugging you could run a whole bunch of times just to figure out what your bug is.
As a free user currently I could potentially be swayed to paying for the pro plan (If it was per-day) but the enterprise plan is completely out of my price range.
7 Likes
For me postman was a very important tool the last 2 years and even considering that iāll have to rebuild everything with another tool pains me greatly.
The paywall to an existing feature was very sudden and it hit us in a critical stage of development. Therefore i canāt help but see some resemblance to ransomware. Luckily iām used to Newman and I can make do with the Newman workaround for now. But what does the future hold?
I donāt want to rely on the whims of the creators of the tool that iām using. Abandoning postman will not be without difficulties, but if Postman decides to lock existing features on such a short notice with so little reasoning and transparency, the transition to another tool will become a necessity.
9 Likes
I have to reluctantly agree with Valentine - in my personal network I have never seen a Postman update land so badly. Reading a lot of blogs, comments and general posts about this. None are good.
Postman is a tool that I have a long relationship with and am a huge fan of. The community and positive regard for this amazing platform is unparalleled.
People feel very unsupported by this change, and Iām gutted for the team at Postman who have to support it. I hope all the bad press and feedback will encourage a rethink.
5 Likes
Iām following on a brilliant course about Postman and API testing by vdespa. I was experimenting with collection runs and from my experience 25 runs are not enough even for learning purpose.
I was evaluating Postman for API test automation in my company but I doubt that Enterprise plan will be within the budget. Basic/professional plans are more affordable for small companies but with these limitations they are not useful at all.
7 Likes
This is a sad moment for the Postman community. How is this pricing move aligned with Our Open Source API Philosophy | Postman Apart from the button in the UI how much of the local run is dependent on the underlying open source projects?
Work on load-testing features with cloud agents and make people pay monthly for actual cloud resources.
5 Likes