Accident Forgiveness

Accident forgiveness behavior across clouds

• Many commenters report major cloud providers (AWS, GCP, etc.) routinely forgiving large accidental bills, especially for key leaks, runaway serverless, or student projects, often after the user explains and fixes the underlying issue (e.g., following security checklists).
• Others note highly publicized cases where forgiveness only came after social media backlash (e.g., large Netlify overage), or where large AWS bills tied to design mistakes weren’t forgiven.
• Some point out that forgiven cases are under‑reported (no blog post), so HN-visible incidents are not representative.
• Several note that providers also change products after high-profile incidents (e.g., new S3 error-code billing changes).

Should “accident forgiveness” be table stakes?

• Many view it as basic hygiene rather than a special perk; others argue that even if it “should be,” it’s still valuable when a provider explicitly commits to it.
• Debate over whether costs are “socialized”: some argue customers inevitably pay for others’ mistakes; others respond that transient excess usage often has near-zero marginal cost given existing overcapacity, so forgiving it is mostly goodwill.

Hard billing caps vs. forgiveness

• Large part of the thread: users—especially hobbyists and small/bootstrapped teams—strongly want hard or configurable spend caps, preferring outages to any chance of a life‑changing bill.
• Cloud-side arguments against caps:
  • Terminating service is often worse than a surprise bill for “serious” apps.
  • Billing systems are complex, distributed, and eventually consistent; using them in tight control loops is hard.
  • Unclear semantics: what exactly to shut off (compute vs. storage vs. backups), when to do it, and how to avoid data loss or unexpected critical outages.
  • Users misconfigure and forget caps; later outages at scale would generate their own outrage.
• Users propose alternatives: soft/hard thresholds, rate-based caps, alerts/webhooks, partial throttling, or explicit “insurance-like” add-ons. Some smaller platforms have begun offering spend limits.

Cloud pricing complexity and alternatives

• Complaints that cloud pricing is opaque, with “black box” adjustments and high egress costs that lock customers in.
• Some advocate cloud-agnostic setups with Kubernetes and open-standard services, or simply using fixed-price VPS/bare metal (Hetzner, Linode, Ionos, etc.) where bills are predictable and bandwidth is cheap.

Perception of Fly.io

• Commenters generally appreciate Fly’s “human” tone, transparency, and willingness to forgive accidents, but criticize the lack of caps for small users and some documentation confusion around default offerings.
• Fly representatives stress focus on professional customers, investment in better anomaly detection and line‑item vetoes, and skepticism toward hard caps, while acknowledging strong user demand and leaving the door slightly open.