Adding my monthly usage billing to my website's dashboard

Posted July 28, 2015 3k views
PHPDigitalOceanAPIPHP Frameworks


I have a dashboard for a website I run, and I wanted to add my monthly usage bill that it’s currently set at. (For example, for 10 hours @ $0.03/hr, it should show $0.30 on my dashboard.)

The thing is, it’s slightly inaccurate, missing 6 cents. (Essentially, 2 hours is missing.)

I am using PHP and Carbon to do this:

$startOfMonth = new Carbon('first day of this month midnight', 'America/New_York');
$currentDay = new Carbon('now', 'America/New_York');

return $currentDay->diffInHours($startOfMonth);

As of right now, it should be 640+ hours for the duration of this month. I set the timezone as New York (I’m in the UK) as I assumed the billing process is handled at DO’s headquarters which is in NYC.

I am also using Graham Campbell’s Laravel-DigitalOcean repo and it does output an object which tells me the hourly cost.

This is how I’m doing the mathematics:

$droplet->getPriceHourly() * $droplet->getHourDurationThisMonth()

What am I doing wrong to receive this inaccurate output?

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

Submit an Answer
1 answer

There are a few things that could be throwing off your calculations slightly:

1.) The pricing shown on the pricing page is rounded to the nearest 1/10th of a cent. A more exact pricing table is below:

512MB -- $0.00744
1GB -- $0.01488
2GB -- $0.02976
4GB — $0.05952
8GB -- $0.11905
16GB -- $0.2381
32GB -- $0.47619

2.) All our droplets are billed at their hourly rate only until they reach their cap. A 512MB droplet would be charged at $0.00744 until that total for the current calendar month reaches $5.00 at which point it stops until the new month starts

3.) Our internal systems (droplet management and billing) run on UTC time and not NYC time. Since we have droplets in data centers all over the world, using a standard rather than standardizing on our own local time made more sense.