Michael JohnsonGår det att begränsa utgifterna för molnberäkning utan att riskera att en produktionsapplikation stannar? Cloudflare erbjuder nu båda inställningarna, men en hård gräns fungerar som en avstängningsknapp för produkten på kontonivå: när tröskeln nås blockeras nya åtgärder som omfattas. Själva tröskeln garanterar dock inte ett högsta fakturabelopp.
Den 13 november 2026 meddelade Cloudflare att Spend Management lanseras för kunder med Pay-as-you-go. Vid lanseringen finns gränser och aviseringar för Workers och Durable Objects. Det är ett automatiskt skydd mot oväntad ökning av förbrukningen – förutsatt att teamet förstår vilka tjänster som omfattas av ett gemensamt stopp, vilket Cloudflare förklarar.
Vad har förändrats jämfört med en utgiftsavisering?
En avisering meddelar att utgifterna har nått en vald nivå, medan produkten fortsätter att fungera. En hård gräns blockerar åtgärder som omfattas. I Spend Management ställs en egen policy in för varje produkt: gränsbelopp, aviseringsnivåer och, om så önskas, en e-postadress. Gränserna för Workers och Durable Objects är oberoende av varandra och omfattar hela respektive produkt i kontot. Det går inte att ställa in en tröskel för en enskild Worker, ett separat namnområde för Durable Objects eller ett enskilt mätvärde, enligt Cloudflares dokumentation.
Det praktiska valet är enkelt: avisering passar när tillgänglighet är viktigast, medan en blockerande gräns passar när teamet är berett att stoppa produktens åtgärder som omfattas för att begränsa fortsatt förbrukning.
Varför utlöses inte gränsen exakt vid det angivna beloppet?
Kostnadsredovisning och spridning av blockeringen sker inte omedelbart. Cloudflare beskriver kontrollpanelen som en vy över utgifter nästan i realtid – med en fördröjning på mindre än 10 minuter. Samtidigt ligger kostnadsberäkningsmotorn inte i vägen för varje begäran. Policyn sprids asynkront till nätverkets noder, och körmiljön tillämpar den när dess lokala tillstånd uppdateras regelbundet. Så förklarar Cloudflare hur Spend Management fungerar.
Den inställda tröskeln är därför den punkt där blockeringen ska börja, inte en hård övre gräns för slutfakturan. Åtgärder kan fortsätta medan utgifterna registreras och regeln sprids. Vissa avgifter omfattas inte heller av gränsen: exempelvis är abonnemangsavgiften för Workers Paid undantagen, och lagrade Durable Objects-data kan fortsätta att medföra kostnader efter en paus. Cloudflare varnar för att det är fakturan som visar slutbeloppet.
Vilka delar av applikationen stoppar Workers-gränsen?
Workers-gränsen samlar utgifter för begäranden och CPU-tid för alla Workers i kontot, efter avdrag för den inkluderade mängden. När blockeringen träder i kraft avvisar Cloudflare nya kodanrop som medför kostnader. Statiska resurser som levereras utan att Workers-kod körs fortsätter att fungera. Så beskrivs omfattningen i Workers-dokumentationen.
Tänk dig ett konto med en produktionsapplikation och en test-Worker. Om testbelastningen driver de sammanlagda Workers-utgifterna upp till tröskeln kan blockeringen även påverka produktionskoden i samma konto. Det går inte att dela upp gränsen mellan enskilda applikationer. För att isolera effekterna kan teamet fördela motsvarande belastningar på olika konton eller välja aviseringar om det inte är acceptabelt att Workers stoppas.
Durable Objects har en separat gräns som omfattar begäranden, körningstid, läsning och skrivning av SQLite-rader samt läs-, skriv- och raderingsåtgärder i nyckelvärdeslagringen. Den omfattar inte Workers, Workers AI, KV, R2 eller andra produkter. Om en applikation är beroende av flera tjänster skyddar en gräns bara motsvarande del av utgifterna, och ett stopp av en enskild komponent kan ändå störa applikationen.
Vad bör du kontrollera innan du aktiverar blockering?
Gör en karta över kontots beroenden: vilka applikationer använder Workers, vilka bakgrundsjobb startar schemaläggningar eller köer och vilka tjänster anropar Durable Objects. Bestäm sedan för vilka produkter ett automatiskt stopp är acceptabelt. Om ett avbrott är värre än en kostnadsökning bör du ställa in en aviseringströskel utan blockering. Om blockering är acceptabelt väljer du ett belopp med hänsyn till fördröjningen i hanteringen, inkluderade kvoter och kostnader som gränsen undantar.
Cloudflare beskriver hur inställningen görs via kontrollpanelen, cf CLI och REST API. När en policy till exempel skapas via API används fältet threshold_cents för beloppet i cent, product_id för produkten, action för åtgärden och notification_email för aviseringar. Ett exempel finns i företagets tillkännagivande. Att automatisera konfigurationen ändrar inte omfattningen: gränsen är fortfarande gemensam för produkten i kontot.
Bestäm i förväg också hur tjänsten ska återställas. För att häva stoppet före nästa faktureringsperiod rekommenderar Cloudflare att höja gränsen över de ackumulerade utgifterna, inaktivera gränsen eller ta bort policyn. Ändringar kan ta flera minuter att träda i kraft; om samma gräns aktiveras igen nollställs inte utgifterna för den aktuella perioden.
När är den här mekanismen användbar?
Spend Management lägger till en automatisk reaktion på ökad förbrukning: i stället för att bara skicka ett e-postmeddelande kan systemet stoppa nya åtgärder som omfattas för den valda produkten. För ett konto med testjobb kan detta fungera som ett skydd mot okontrollerad belastning. För ett konto med flera verksamhetskritiska tjänster kopplar den gemensamma gränsen samman budgeten och tillgängligheten för alla Workers eller alla Durable Objects i kontot.
Valet beror på vilken kostnad ett stopp får ha. Om driftskontinuitet är viktigast börjar du med aviseringar och övervakning av utgifterna. Om det är viktigare att begränsa fortsatt användning aktiverar du blockering efter att ha kontrollerat beroendena och förberett återställningen. Planera tröskeln som en policy för att stoppa produkten, inte som ett löfte om ett exakt fakturabelopp.
