Michael JohnsonKan man begrense kostnadene for skybasert databehandling uten å risikere at en app i produksjon stanser? Cloudflare tilbyr nå begge innstillingene, men en hard grense fungerer som en bryter for produktet på kontonivå: Når terskelen nås, blokkeres nye operasjoner som omfattes. Terskelen garanterer likevel ikke et maksimalt beløp på regningen.
13. november 2026 kunngjorde Cloudflare lanseringen av Spend Management for Pay-as-you-go-kunder. Ved lansering er grenser og varsler tilgjengelige for Workers og Durable Objects. Dette er en automatisk sikring mot uventet økning i forbruket – forutsatt at teamet forstår hvilke tjenester som omfattes av samme felles stans, slik Cloudflare forklarer.
Hva er endret sammenlignet med kostnadsvarsler?
Et varsel sier fra når kostnadene har nådd et valgt nivå, mens produktet fortsetter å kjøre. En hard grense blokkerer operasjoner som omfattes. I Spend Management angis en egen policy for hvert produkt: grensebeløp, varslingsterskler og, hvis ønskelig, en e-postadresse. Grensene for Workers og Durable Objects er uavhengige av hverandre og omfatter hele det aktuelle produktet i kontoen. Det er ikke mulig å angi en terskel for én Worker, ett eget navnerom for Durable Objects eller én enkelt måling, ifølge Cloudflares dokumentasjon.
Valget i praksis er enkelt: Varsler passer når tilgjengelighet er viktigst, mens en blokkerende grense passer når teamet er villig til å stanse produktets aktuelle operasjoner for å begrense videre forbruk.
Hvorfor utløses ikke grensen nøyaktig ved det angitte beløpet?
Kostnadsberegningen og spredningen av blokkeringen skjer ikke umiddelbart. Cloudflare beskriver kontrollpanelet som en visning av kostnader nesten i sanntid – med en forsinkelse på under 10 minutter. Kostnadsmotoren ligger imidlertid ikke i behandlingsløpet for hver enkelt forespørsel. Policyen spres asynkront til nettverksnoder, og kjøremiljøet tar den i bruk når den lokale tilstanden oppdateres periodisk. Slik forklarer Cloudflare hvordan Spend Management fungerer.
Den angitte terskelen er derfor punktet der blokkeringen skal begynne, ikke en hard øvre grense for den endelige regningen. Mens kostnadene beregnes og regelen spres, kan operasjonene fortsette. Enkelte kostnader omfattes heller ikke av grensen: For eksempel er abonnementsavgiften for Workers Paid unntatt, og lagrede data i Durable Objects kan fortsette å påløpe kostnader etter en pause. Cloudflare advarer om at det er regningen som viser det endelige beløpet.
Hvilke deler av appen stanser Workers-grensen?
Workers-grensen samler kostnadene for forespørsler og CPU-tid for alle Workers i kontoen, etter fradrag for inkludert forbruk. Når blokkeringen trer i kraft, avviser Cloudflare nye kodekall som medfører kostnader. Statiske ressurser som leveres uten å kjøre Worker-kode, fortsetter å fungere. Dette er virkeområdet som beskrives i Workers-dokumentasjonen.
Tenk deg en konto med en app i produksjon og en Worker for testing. Hvis testbelastningen driver de samlede Workers-kostnadene opp til terskelen, kan blokkeringen også ramme produksjonskoden i samme konto. Grensen kan ikke deles opp per app. For å isolere konsekvensene kan teamet legge de aktuelle belastningene i separate kontoer eller velge varsler dersom det ikke er akseptabelt at Workers stanser.
En egen grense for Durable Objects tar med forespørsler, kjøretid, lesing og skriving av SQLite-rader samt lesing, skriving og sletting i key-value-lageret. Den omfatter ikke Workers, Workers AI, KV, R2 eller andre produkter. Hvis en app er avhengig av flere tjenester, beskytter én grense bare den relevante delen av kostnadene, og stans av ett ledd kan likevel forstyrre appen.
Hva bør du kontrollere før du aktiverer blokkering?
Kartlegg kontoens avhengigheter: hvilke apper som bruker Workers, hvilke bakgrunnsoppgaver som utløses av tidsplaner eller køer, og hvilke tjenester som kaller Durable Objects. Bestem deretter for hvilke produkter automatisk stans er akseptabelt. Hvis et avbrudd er verre enn overskridelse av budsjettet, bør du angi en varslingsterskel uten blokkering. Hvis blokkering er akseptabelt, velger du et beløp som tar høyde for behandlingsforsinkelsen, inkluderte kvoter og kostnader som grensen unntar.
Cloudflare beskriver oppsett via kontrollpanelet, cf CLI og REST API. Når en policy for eksempel opprettes i API-et, brukes feltet threshold_cents for beløpet i cent, product_id for produktet, action for handlingen og notification_email for varsler; et eksempel finnes i selskapets kunngjøring. Automatisering av oppsettet endrer ikke virkeområdet: Grensen gjelder fortsatt produktet i hele kontoen.
Bestem på forhånd hvordan tjenesten skal gjenopprettes. For å oppheve stansen før neste faktureringsperiode foreslår Cloudflare å heve grensen til et beløp over de akkumulerte kostnadene, deaktivere den eller slette policyen. Endringer kan ta flere minutter før de trer i kraft. Hvis den samme grensen aktiveres på nytt, nullstilles ikke kostnadene for inneværende periode.
Når er denne mekanismen nyttig?
Spend Management legger til en automatisk reaksjon på økt forbruk: I stedet for bare å sende en e-post kan systemet stanse nye operasjoner som omfattes, for det valgte produktet. For en konto med testoppgaver kan dette fungere som en sikring mot ukontrollert belastning. For en konto med flere kritiske tjenester knytter en felles grense budsjettet og tilgjengeligheten til alle Workers eller alle Durable Objects i kontoen sammen.
Valget avhenger av hva en stans vil koste. Hvis kontinuerlig drift er viktigst, bør du begynne med varsler og følge med på kostnadene. Hvis det er viktigere å begrense videre bruk, kan du aktivere blokkering etter å ha kontrollert avhengighetene og forberedt gjenoppretting. Terskelen bør planlegges som en policy for å stanse produktet, ikke som et løfte om et nøyaktig beløp på regningen.
