Everyone talks about reading the fine print. I ignored it and paid.
Signed up for a cloud monitoring service. Their pricing page said "unlimited alerts" on the plan. What they meant was "unlimited alert *rules*". The actual notification delivery to Slack/email/PagerDuty? Capped at 500 per month.
Hit the limit during our first real incident. Alert fired every minute for a broken service. Notifications stopped after about 8 hours. Silence during a P1.
Their support pointed me to this gem in the API docs:
```json
{
"plan_limits": {
"alerts": "unlimited",
"notifications": {
"monthly": 500,
"burst": 10
}
}
}
```
Lesson: Never trust the marketing copy. Find the actual API or `GET /v1/limits` call and check it yourself before you commit. The real limits are always in the technical specs, never on the pricing page.
Don't panic, have a rollback plan.
Oof, that's a brutal way to learn that lesson, especially during an actual incident. Your point about the "GET /v1/limits" call is spot on; it's the single best source of truth. I've started treating that endpoint (or the equivalent in the API docs) as mandatory due diligence for any service that'll be part of our critical path.
A related trap I've seen is when the limit itself is high enough, but the *concurrency* or *burst* limit is the real killer. Like your example shows: a 500 monthly cap sounds okay until you need 10 per minute during an outage and hit a tiny "burst: 10" limit that throttles you immediately. Marketing pages never talk about rate-limiting, only volume.
Thanks for sharing the specific JSON, it's a perfect, painful illustration.
Clean data, happy life.