What's the minimum time counted for billing in Heroku? - heroku

Ec2 instance hour calculated by hour by hour. If you just start and close an instance, it still counted as one hour.
How Heroku handle this? By Minute or By Hour?
Lets assume my app usage exceeds 750 Free Dyno Hour Limit


Heroku prorata to the second. A dyno costs $0.05 per hour. So if you go over 750 hours you will be charged at $0.05 per hour or $0.000833333 per minute. In fact, pretty much all addons also follow the same billing model too.
You can read about billing and charges as https://devcenter.heroku.com/articles/usage-and-billing#cost


I will say, though, that the previous answer seems to be more accurate for the web dyno versus a worker dyno. Heroku's automated sleep cycle for your web dyno tries to prevent it from running too long when it's idle, say, for more than an hour. For the free web dyno it must sleep at least six hours per day for it not to incur charges. As long as you set the scaling to 1 for your web dyno and it sleeps then it should be free.
That said, when you add your first worker dyno those same automations aren't applied to this dyno. It presumably won't be triggered to sleep on idling for an hour. This means that unless you manage it you'll likely be charged $34.50 for each worker dyno per month. I wouldn't exactly call this lying to the customer but most people start off with that first free dyno, get comfortable with that and then innocently think that the next dyno will behave in a similar way--it won't and you'll likely get tagged paying more money than you'd bargained for. That's $414-per-year for a dyno. Compare this with Amazon's t2.micro cost of $150-per-year for one instance or $75-per-year for a 50% duty cycle of same.
As they say, "the devil is in the details". Heroku might be cheap for vanity websites but it's a bit costly if you have a database and worker thread (without any scaling otherwise whatsoever).

Related

Heroku pricing dyno confusion

I'd like to buy a "Hobby" package on Heroku but I'm confused by the pricing. It says $7 per Dyno per month, but then it also says you pay for the fraction of actual processing time. So if I have a thousand 100ms requests a day thats just 50 minutes a month. So do I pay 7/(30*24*60)*50 dollars for that total?
What if I dont have a single request for a month at all? Do I still need to pay?
thank you
Edit: I meant minutes, even less then

If your dyno runs 24*7 the whole month you have to pay 7$.
If your dyno runs just one day in a month you pay 7/30 $.
This is what "fraction of actual processing time" means.
So the Hobby Dyno won't cost more then 7$.

How exactly does AWS EC2 count hourly costs?

Simple question:
If I had six identical EC2 instances process data for exactly ten minutes and turn off would I be charged six hours or one hour?

Update: EC2 and EBS are now based on usage down to the second
Old answer
Granularity for changes are measure down to the hour.
From the AWS pricing site http://aws.amazon.com/ec2/pricing/:
Pricing is per instance-hour consumed for each instance, from the time
an instance is launched until it is terminated or stopped. Each
partial instance-hour consumed will be billed as a full hour.
Unless you are calculating time to be under a threshold for a free tier, the second you use an EC2 instance you're charged for the full hour. If you go one second over the first hour, your charged for a full second hour.
One caveat: Spot Instances.
If spot instances are interrupted by AWS (not you) before reaching a full hour use, you're not charged at all. If you interrupt the spot instance, you're charge for the partial hour usage (which is a full hour rounded up as per the on-demand instances).

AWS has introduced per second billing for EC2/EBS effective October 2, 2017.
New EC2 Billing

You always get 750 hours per month for all your ec2 instances.
Different cases:
Case 1: Your have created and running one instance for 10 minutes.And then stopped.
It will be counted as 1 hour.
Case 2: Your have two running instances for each for 5 or 10 minutes and then stopped. It will be counted as 2 hours.
Case 3: You have one instance running for 10 minutes, then stopped and then again started for 10 or 5 minutes. It will be counted as 2 hours.
You can only use t2.micro servers and some limited OS in free tier.
This way, you can prevent your unwanted billing.
I hope, this has cleared some doubts.
Note: This is just my understanding till today. Please check their(aws) pricing docs for updated information.

Heroku web dynos often slowing down but never getting more than 20% load?

A couple of times a day we see the response time of any one of our Heroku web dynos increase tremendously. We have been analyzing this with little success so far.
One strange thing we see, however, is the following. Look at this "Instances running" graph from New Relic:
You see that we've played around with the number of web dyno's, but the majority of the time we have had 2 dynos with 4 Unicorn processes each. But never ever do these instances seem to get the "full load". How should we interpret this? Is this just that at any time the sum of CPU usage of all instances never exceeds approx. 20%? And if so, it seems we're really underutilizing our dynos. What can we optimize here?
For clarity: the average memory usage is constant between 110MB and 120MB, so that does not seem to be the bottleneck.

Have you seen http://news.rapgenius.com/James-somers-herokus-ugly-secret-lyrics ?
Heroku has worked on addressing this, but you'll need to talk to them for further recommendations.

Dyno pricing confusion

The following statements seem contradictory to me
Dynos cost $0.05 per hour, prorated to the second. For example, an app with four dynos is charged $0.20 per hour for each hour that the four dynos are running.
Pricing is based on calendar time. If you set your app to four dynos, you will be charged $0.20 per hour regardless of the traffic your site serves during that time.
(as seen here)
I'm reading it as "you will be charged for a running dyno" then "you will be charged whether or not the dyno is being used"
Please clarify my understanding, because it seems most people don't have this same confusion.

A Heroku dyno is considered running when it is ready to receive requests, not necessarily when it is actually serving requests. To rephrase:
For example, an app with four dynos is charged $0.20 per hour for each hour that the four dynos are provisioned

Average EC2 Uptime?

Curious as to 99.95% uptime REALLY means; Is it really going to go down 7 minutes a month? Please post your longest/average uptimes on EC2, thanks.

Usually uptime is calculated in a yearly basis. So if you have a Service Level Agreement for 99.95% this means:
365 * 0.0005 = 0.1825 days or 4.38 hours
If during a year of service there is an outage and your system is down for more than that, then you are liable for compensation.
As of your question, I have a server running unstopped in EC2 for about 3 months now. I would say that their uptime is good, but if you have a mission critical application you definitely need to have a fail-over solution. A good uptime only means that they will be able to respond to an outage quickly. Even a 99.9999% uptime won't be able to save you if you aren't prepared for an outage.

Read the SLA carefully (http://aws.amazon.com/ec2-sla/) they only count "Region Unavailable" as downtime, and what is more they only count it as downtime if the region is down for 5 consecutive minutes.
“"Annual Uptime Percentage” is calculated by subtracting from 100% the percentage of 5 minute periods during the Service Year in which Amazon EC2 was in the state of “Region Unavailable.”
By my count this mean any downtime of less then 4 minutes is not countable. Also if they do break the SLA they are only in for %10 of the month in which you had largest downtime bill.
So if they where down for all of January and your bill was $100 they would apply a $10 credit to your account.
I would have a hard time convensing my boss that this is a serious product with a SLA like that.

SLA's are useless. They only measure how much risk the company is willing to take on and have no bearing on actual uptime. I've seen SLA's, with heavy penalties, offered when the company knew the could not meet the SLA in order to land the sale.
I have one client with 400+ days of EC2 uptime and another with 300+ days as measured by web pulse, this is by far the most reliable service I've worked with.

For my single instance running in the US-East availability zone, 9 months, 0 downtime.

Since Amazon switched to provide an SLA, I've never had an instance go down on me. When I've had instances go down in the past, Amazon has always sent a message informing me that the instance is degraded before it actually disappeared, so I've had time to start up a new instance.
The previous answer makes a good point, though; EC2's service model dictates that you write your apps to handle failover to a new server if you're not prepared for extended down time.

conrad#papa ~ $ uptime
04:42:36 up 495 days, 8:51, 8 users, load average: 0.02, 0.02, 0.00

Checking out the AWS Service Health Dashboard will get you a good idea of any current or past issues. My experience is that the AWS uptime is better than most "traditional" hosting options (even full-blown redundant RackSpace setup...).
However, simply going with AWS for uptime is like getting a car for the keychain (ok, almost.. ;)). With an architecture utilizing AWS the big benefit is scaling (without upfront costs).

SLA... Guaranteed uptime...
These are all very nice taglines. But when the servers aren't available for an hour (March 1, 2012, in the EU region) and the clients start calling, then it won't help you that they still have a 300 days uptime.
And when the lightning struck 1 out of 3 of their datacenters in the EU, we all found out that they have no off-site redundancies, and the fact that they have 3 datacenters doesn't mean a thing.
One must love the phrase "degraded performance", that actually means: "cross your fingers and pray that your data will still be available after the catastrophe passes".
I'm still trying to look for any official/non-official statistics about the availability percentages of all of their datacenters.
No luck thus far...

I've never had downtime on EC2, however, I do keep local backups and make daily images of my machines and port them to another availability zone, just in case. I use twilio to alert me if a machine is unreachable with a phone call to all my devices. Then I can just log in to EC2 and fire up a machine in another availability zone; worst case I'll be down for a few minutes.
Which in my case, is potentially pretty sucky, because my machines are doing 24/7 Forex trading.
My rule: know the potential cost of downtime, and be willing to invest that much in redundancy assuming it will happen - because it will.
That said, EC2 has never let me down. Helps probably that my servers are not in an area of the country where natural disasters are common. If you're in an earthquake zone, tornado alley, or a potential hurricane path, downtime truly is an inevitability.

Resources