Google Cloud uptime checks can cost you more than running what they are checking
Starting October 1st Google started charging $0.30 per 1000 uptime checks - it was free before.
Some quick math:
- 60 checks per hour * 24 hours * 30 days = 43200 billable checks per month, or $12.96, but
- you are required to run those checks from at least 3 locations, so 12.96 * 3 = $33.88 minimum, but
- the default is "global" or 6 locations. That setting is hidden in UI in collapsed section "more target options". To make things worse a single location checkbox "United States" actually enables 3 locations - 3 data centers in US
That's a $38.88 minimum and $77.76 default. Running a 2 vCPU + 8GB RAM + 10GB storage VM in Google Cloud for a month costs $50.34.
By comparison Pingdom will charge at most $1 per uptime target with it's smallest plan of 10 targets and will throw in advanced checks and SMS downtime alerts in that price. With larger plans you can get closer to $0.60.
If you run a lot of small VMs and have an uptime check for something running on each of them you will end up paying more for the uptime checks than VMs. Don't ask how I know.
6 comments
[ 2.6 ms ] story [ 27.6 ms ] threadI.e. you can have 7 checks running every minute in 3 locations before you get charged. (1e6/(60*24*31*3) =7.4)
It's a hosted Status Page, with built-in Uptime Monitoring. It supports:
* Custom domains
* Private Status Pages (password protection)
* Automatically posting incidents to your status page based on uptime monitoring (either using our monitoring, or Uptime Robot integration - more integrations coming soon!)
* Subscribing to incident updates via Email
Our uptime monitoring supports websites, web apps, and APIs, and can send you alerts via:
* Email
* SMS (BYO Twilio account)
* Webhooks
* Slack/Discord
Always happy to chat if you have thoughts or questions
How hasn't this been raced to the bottom yet? Seems like a lot for something that seems fairly simple and scalable
Workflows + Cloud Scheduler can perform checks for about $0.53 per region per month. Create a workflow calling the endpoint, wrap it in a try/retry/except (possibly using a custom predicate), and add a trigger to run it every minute. As bonuses, you get full execution history and can write very flexible logic for remediation.
One trick is you'll want to store some kind of global flag on an outage so you don't keep triggering your remediation every minute throughout the outage. Firestore works well for this. (If you really want no dependencies, you can get clever with the workflow sleeping and triggering itself with state rather than using a recurring trigger.)
https://cloud.google.com/stackdriver/pricing#monitoring-pric...