[runako]

Do people really prefer to see vCPU pricing in per-second increments? Is this useful for any person?

Presumably no information is conveyed by the first 4 significant digits. And can anybody compare this pricing to e.g. AWS or Google Cloud? I have never known my compute cost to second resolution, so I'd need to do calculations to even ballpark this.

Suggestion: Don't obfuscate the price, just remove it. Clearly you don't really want casual browsers to know how much you're charging[1]. Which: fine, this is the current trend in tech. So just remove the pricing and put your calendar link there as a CTA instead. Be classy. Don't play games with your audience.

1 - anybody who plugs this into a calculator will a) understand why you don't show monthly pricing and b) think this is screamingly expensive. Which reinforces my recommendation to just replace the price with a CTA and your calendar link.

[rcxdude]

There is a useful signal in such a way of indicating pricing: it signals that the billing is done at such a resolution, which, for some workloads, can make a difference compared to say, a minimum increment of an hour or a day. Though I would prefer that you can see the conversion to longer timescales on the page itself.

[runako]

I thought about that, which is indeed what AWS Lambda does, but one of the pitches here is "Always-on VMs," which is not what Lambda is selling.

[Glemllksdf]

For CI/CD Jobs? Yes.

For a VM running for a month? No.

For highly scalable batch tasks? Yes.

For small experiments? Yes.

For Full e2e tests creating a full env and killing it a minute later? yes.

[runako]

One of the info blocks is headed "Persistent VMs" and suggests "Always-on VMs..."

They are not pitching this for any of the "yes" tasks you identified.