It's Saturday morning. You check your email, and there it is — an alert from OpenAI that you've just hit your monthly billing limit. Except it's the seventh of the month. You had three weeks of budget left thirty-six hours ago. What the hell happened?
Here's what happened: one of your n8n flows had a loop. A webhook you thought was debounced was firing every few seconds. Each fire hit the OpenAI API. Each hit cost a few cents. Between midnight Friday and now, you burned through four hundred dollars of budget that was supposed to last you a month.
This is the runaway-billing nightmare, and every serious AI builder has a version of this story. The scary part is how silent it is — APIs don't call you to warn you. They just keep charging. By the time you see the bill, the damage is done.
Why the providers' own alerts aren't enough
OpenAI, Anthropic, and the rest all have usage dashboards. They all have some form of billing alerts. In theory, you shouldn't need a third-party tool for this.
In practice, there are two problems. First, each provider's alerts are siloed. You have to configure them per-provider, remember to check them, and aggregate across a dozen accounts to get a total view. Second, the alerts are slow — many providers batch billing data and only evaluate thresholds every few hours, which is plenty of time for a runaway loop to do real damage.
IBYOK's alerts are cross-provider and threshold-based. You set your total budget — across all the providers your vault tracks — and get pinged at 50%, 75%, 90%, and 100%. Not after the dust settles. As it's happening.
The four-threshold approach
Why four thresholds? Because each one means something different.
50% is the "awareness" alert. By the middle of your billing window, you should have burned about half your budget. If you hit 50% in the first week, something's off — your traffic is higher than expected, or a recent integration is more expensive than you planned. It's an early signal to look, not panic.
75% is the "look now" alert. This one you act on. You're three-quarters through your budget, which means you should have enough runway but not much cushion. Time to check whether something's running away, and whether you should throttle or pause anything before you hit 100%.
90% is the "act immediately" alert. You've got about a tenth of the month's budget left. If your usage is steady, you're going to run out before the reset. Time to either raise the limit, kill a non-critical integration, or at minimum stop any loop you don't absolutely need.
100% is the "your systems are about to break" alert. Hit this and your API calls start failing. If you're serving production traffic, this is now an incident. The 100% alert exists so you're not finding out via angry customer emails.
Four alerts, each with a different urgency and a different action. That's why the 50/75/90/100 spacing works — it gives you the graduated response that a single "you're out of budget" email doesn't.
Graduated alerts across every provider — stop finding out about runaway loops too late.
The runaway loop scenario
Let's walk through the specific scenario this feature was built for. You're running an n8n flow on your Hostinger VPS. It listens to a webhook, does some ChatGPT processing, and writes results to your CMS. On paper, it fires maybe ten times a day.
You push an update Friday evening. Somewhere in the change, a retry loop goes infinite — a condition that was supposed to check "did this succeed?" ends up always returning false, triggering a retry every five seconds, each retry making a fresh OpenAI call.
Without IBYOK alerts, you find out Monday morning when the billing email hits. Forty-eight hours of infinite loop. Hundreds of dollars. You're filing a support ticket with OpenAI hoping for a partial refund, feeling like an amateur.
With IBYOK alerts, you get the 50% notification Saturday morning — hours after the loop started, but still within the blast radius you can recover from. You check, find the loop, kill it. Maybe fifty dollars over budget instead of four hundred. A bad morning instead of a ruined weekend and a week of embarrassment.
The "I didn't know my app was expensive" problem
There's a second scenario that's less dramatic but more common: slow-creep usage. Your app traffic grows modestly week over week. Your per-request cost is fine. But the cumulative cost is rising faster than you expected, because each new user generates API calls, and there are more users every week.
Without alerts, you find out about this at the end of the month, when your invoice is suddenly 40% higher than last month. With alerts, you see the 50% hit the third week of the month instead of the halfway point, and you realize "okay, my user base is outpacing my budget." You can plan — raise the limit, optimize the expensive endpoint, or just add a per-user cap.
Visibility beats firefighting. That's the whole argument for graduated alerts: they turn invisible cost dynamics into visible ones, which turns reactive budget crises into proactive capacity planning.
Alerts across every provider in one place
One of the quieter benefits of running alerts through IBYOK is that they're unified across providers. Your OpenAI spend, your Anthropic spend, your HeyGen spend — all in one rollup. You don't have to chase down four dashboards to see whether you're approaching your total AI budget.
For solo builders running a real stack, this unified view is probably more valuable than the individual alerts themselves. You stop thinking "I've got budget on OpenAI but I'm close on Anthropic" and start thinking "my AI stack is at 80% of my monthly budget, and here's the breakdown." That's the frame a CFO would use, and for indie builders it's the same discipline — just applied to a stack you own.
What it doesn't do
Fair warning: IBYOK alerts don't automatically throttle your app. They warn you. You still have to go turn things off. That's intentional — the cost of incorrectly killing a production integration is usually higher than the cost of a few extra dollars of usage, and IBYOK can't know which of your flows are critical.
If you want automatic throttling, you can build it on top of the alerts — have the 90% alert trigger a webhook that pauses non-critical services, for instance. But out of the box, IBYOK gives you the visibility and leaves the action to you.
What to do
Set a monthly budget that reflects what you actually want to spend, not what you're willing to absorb. Let the alerts fire. Treat them as data about your real usage pattern, which most builders never look at until they have to.
The first month, you'll probably recalibrate your budget. The second month, you'll probably catch something you didn't expect. By the third month, the alerts will feel like background noise — which is exactly what they should feel like when your system is healthy.
— Jeff
Four thresholds, every provider, no surprise bills.