Salesforce Heroku-storing: Wat gebeurt er met geïmplementeerde applicaties?

Op 16 september 2026 toonde de openbare Heroku Status API-snapshot de status van Apps , Data en Tools als groen, zonder actieve incidenten. Dit is slechts een momentopname en geen garantie dat elke app, regio of afhankelijkheid in goede staat verkeert. Heroku beschouwt de Heroku-statuspagina van Salesforce Trust nu als het primaire kanaal voor incident- en onderhoudscommunicatie, terwijl de oude status-API nog steeds nuttig is voor een snelle programmatische snapshot.

Er speelt ook een belangrijke ontwikkeling op platformniveau mee in de kwestie van de uitval. In de update van 6 februari 2026 gaf Heroku aan over te zijn overgestapt op een onderhoudsmodel gericht op stabiliteit, beveiliging, betrouwbaarheid en ondersteuning. Heroku beschreef het platform als actief ondersteund en klaar voor productie, en zei dat bestaande creditcardklanten geen veranderingen zouden merken in prijzen, facturering, service of dagelijks gebruik. Deze aankondiging betreft een update over de levenscyclus en investeringen – het is geen verklaring dat in gebruik zijnde applicaties worden uitgeschakeld.

Wat een storing bij Salesforce Heroku daadwerkelijk kan betekenen

"Heroku-uitval" is niet één enkele storingsmodus. Heroku's eigen servicecategorieën verdelen het platform in Apps, Data en Tools. De praktische impact hangt af van welke laag is uitgevallen en of uw applicatie zonder die laag kan blijven functioneren.

Impact op applicaties die al in gebruik zijn

1. Een actieve app kan bereikbaar blijven.

Een probleem met het controlepaneel of de implementatietool betekent niet automatisch dat alle actieve dyno's stoppen met het verwerken van verzoeken. De documentatie over de applicatielevenscyclus van Heroku legt uit dat web-dyno's HTTP-verkeer ontvangen via Heroku-routers, terwijl worker-dyno's achtergrondtaken verwerken. Als het getroffen onderdeel het dashboard, de CLI of het implementatiepad is, kan een bestaande webapplicatie blijven reageren, zelfs als een operator niet normaal kan implementeren, schalen, logboeken inspecteren of de configuratie wijzigen.

Het omgekeerde is ook mogelijk: een Tools-service kan in goede staat zijn, terwijl een incident met Apps of routing ervoor zorgt dat de openbare URL niet beschikbaar is. Daarom moet een groen dashboardbeeld – of een mislukte dashboardaanmelding – niet worden beschouwd als een volledige controle van de applicatiestatus.

2. Datastoringen kunnen een gedeeltelijke uitval veranderen in een bedrijfsincident.

Als het app-proces actief is, maar de database of wachtrij niet goed functioneert, kunnen gebruikers een pagina zien die laadt zonder actuele gegevens, mislukte formulierinzendingen, dubbele pogingen of vertraagde afhandeling. Een alleen-lezen pagina kan er normaal uitzien, terwijl het afrekenproces, accountwijzigingen of de orderverwerking stilletjes een back-up maken.

Reageer niet op elke databasefout door het aantal herhaalpogingen te verhogen. Een stortvloed aan herhaalpogingen kan de belasting verhogen en dubbel werk veroorzaken wanneer de service zich herstelt. Geef de voorkeur aan beperkte, idempotente herhaalpogingen; pauzeer niet-essentiële batchactiviteiten indien uw runbook dit toestaat; en registreer welke bewerkingen zijn voltooid, mislukt of waarvan de status onbekend is.

3. Het vertrouwen in de implementatie kan lager zijn dan het vertrouwen in de uitvoering.

Tijdens een Heroku-storing die Git-pushes, de Deployment API, de build-infrastructuur of de logs beïnvloedt, kan een ontwikkelaar mogelijk niet bewijzen of een release de productieomgeving heeft bereikt. Het opnieuw uitvoeren van dezelfde deployment kan verwarring veroorzaken of leiden tot meerdere releases die moeilijk te vergelijken zijn. Leg de commit-ID, het releasenummer (indien beschikbaar), de lokale uitvoer van de opdracht en de tijdstempels vast. Wacht op een officieel herstelsignaal voordat u een gecontroleerde verificatie-deployment uitvoert.

4. De Salesforce-connectiviteit is een aparte afhankelijkheid.

Een incident met Salesforce hoeft de webservers die een Heroku-app hosten niet per se plat te leggen. Een applicatie die afhankelijk is van Salesforce-authenticatie, API-aanroepen, Heroku Connect-synchronisatie of gebeurtenisgestuurde workflows kan echter wel aanzienlijk worden belemmerd. De juiste vraag is niet simpelweg "Is Heroku offline?", maar "Welke gebruikerservaring is afhankelijk van welke service en welke gegevens kunnen veilig worden uitgesteld?"

Hoe stel je een diagnose zonder de situatie te verergeren?

1. Controleer beide officiële kanalen. Begin met Salesforce Trust for Heroku en de Heroku Status API . Volgens de statusrichtlijnen van Heroku moet je contact opnemen met de supportafdeling als er geen incident is gemeld of als de gerapporteerde symptomen niet overeenkomen met jouw probleem.
2. Test buiten het kantoornetwerk. Gebruik een externe synthetische test of een aparte verbinding om de openbare URL, een lichtgewicht status-eindpunt en één representatieve gebruikersactie te testen. Dit onderscheidt een platformgebeurtenis van een lokaal DNS-, firewall- of VPN-probleem.
3. Classificeer de falende bewerking. Zit de fout in de routering, een dyno-proces, een databasequery, een implementatie, logging of een externe API? Een simpele servicemap kan een team ervan weerhouden een verder goed functionerende applicatie te migreren, simpelweg omdat één afhankelijkheid niet beschikbaar is.
4. Beperk risicovolle wijzigingen. Stel niet-essentiële releases, configuratieaanpassingen, add-on-wijzigingen en schaalexperimenten uit totdat de status van het platform duidelijker is. Bewaar bewijsmateriaal in plaats van meerdere variabelen tegelijk te wijzigen.
5. Bescherm de workflows van klanten. Schakel, indien mogelijk, over naar de alleen-lezenmodus, stel niet-kritieke taken uit, toon een expliciete onderhoudsmelding of schakel een defecte integratie uit. Maak het verslechterde gedrag zichtbaar in plaats van verzoeken te accepteren die niet betrouwbaar kunnen worden voltooid.
6. Controleer de synchronisatie na het herstel. Controleer schrijfbewerkingen, wachtrijen, geplande taken, webhooks, Salesforce-synchronisatie en callbacks van derden. Een HTTP 200-respons na het herstel bewijst niet dat alle achtergrondworkflows zijn bijgewerkt.

Welke vorm van veerkracht past het beste bij uw toepassing?

Er bestaat niet één beste architectuur voor noodherstel. De juiste investering hangt af van de kosten van downtime, de vereisten voor de duurzaamheid van uw gegevens en de mate van operationele complexiteit die uw team aankan.

Failover voor meerdere regio's of providers is alleen waardevol als deze onafhankelijk is getest. Een standby-omgeving die dezelfde identiteitsprovider, DNS, datastore, geheimen of implementatiepipeline deelt, kan samen met de primaire omgeving uitvallen. Omgekeerd kan een eenvoudige Heroku-implementatie met goede externe monitoring en een duidelijke 'degraded mode' een betrouwbaardere keuze zijn voor een klein team dat niet twee platforms tegelijk kan beheren.

Wat de Heroku-update van 2026 betekent voor geïmplementeerde apps

Het model voor duurzame ontwikkeling verandert de verwachtingen rondom platformevolutie meer dan dat het het directe gedrag van een bestaande app verandert. Heroku zegt dat de focus ligt op stabiele, veilige en betrouwbare werking en ondersteuning, waarbij nieuw werk is afgestemd op de doelstellingen voor duurzame ontwikkeling. Voor teams die al applicaties in productie draaien, is de bevestigde boodschap aan de klant continuïteit: de kernfunctionaliteit blijft beschikbaar en creditcardklanten hoeven hun dagelijkse gebruik niet aan te passen vanwege deze aankondiging.

De afweging is strategisch. Organisaties die voor Heroku kiezen vanwege de snelle implementatie van nieuwe platformfuncties, moeten de roadmap en contractopties zorgvuldig bekijken. Organisaties die prioriteit geven aan een beheerde implementatie, volwassen applicatieprimitieven en minder infrastructuurbeheer, zullen een op stabiliteit gericht model wellicht anders beoordelen. Heroku heeft ook aangegeven dat er geen nieuwe Enterprise Account-contracten meer worden aangeboden aan nieuwe klanten, terwijl bestaande Enterprise-abonnementen en -ondersteuning wel worden nagekomen en kunnen worden verlengd. Dit is van belang voor inkoop- en toekomstige architectuurbeslissingen, maar het is geen bewijs van een storing of een automatisch risico voor momenteel geïmplementeerde applicaties.

Kortom

De meest recente officiële momentopname, gecontroleerd op 16 september 2026, toonde geen actieve Heroku-incidenten en de aankondiging van Heroku over de ondersteuning van het platform in 2026 beschreef voortdurende ondersteuning. Mocht er zich echter een storing voordoen, dan hangt de impact op een geïmplementeerde applicatie af van de laag die de storing veroorzaakt: apps kunnen de beschikbaarheid beïnvloeden, data kunnen de correctheid en de wachtrij beïnvloeden, tools kunnen de implementatie en observeerbaarheid beïnvloeden en Salesforce of afhankelijkheden van derden kunnen individuele processen verstoren, terwijl de app zelf online blijft.

Gebruik Salesforce Trust als de primaire bron voor incidenten, vergelijk deze met de openbare status-API, test het daadwerkelijke gebruikerspad van buiten uw netwerk en classificeer de afhankelijkheid voordat u actie onderneemt. Kies failover, graceful degradation of een wacht-en-verifieer-reactie op basis van uw hersteldoelstelling – niet omdat elke Heroku-storing dezelfde oplossing vereist.

Officiële referenties

• Heroku: Een update over Heroku (6 februari 2026)
• Heroku Dev Center: Heroku-status (bijgewerkt op 21 oktober 2025)
• Salesforce Trust: Productstatus op Heroku
• Heroku Status API: momentopname van de huidige status
• Heroku Ontwikkelcentrum: Levenscyclus van een Heroku-app