De storing die niet op de statuspagina verschijnt
Op 9 juni 2026 meldden meerdere gebruikers op de Databricks Community-forums dat de loginpagina van de Free Edition gewoon niet wilde laden. Geen foutcode. Geen timeout-melding. De pagina weigerde uren lang te openen en werkte daarna stilletjes weer gewoon. De oorspronkelijke poster vatte het samen: "The issue was resolved by itself on the same day after few hours. Not sure why it was happening."
De Databricks-statuspagina toonde gedurende die hele periode dat alle systemen operationeel waren. Een Community Manager bevestigde dat er geen bekende storing was. Toch ondervonden minstens drie onafhankelijke gebruikers uit verschillende regio's in hetzelfde tijdvenster dezelfde black-out.
Dit patroon is niet uniek voor de Free Edition. Betaalde Databricks-workspaces ondervinden regionale degradatie die onder de drempel voor een formeel incident blijft. Een hiccup in het control plane in één availability zone. Een serverless compute pool die 12 minuten nodig heeft om te provisioneren in plaats van 90 seconden. Een OAuth token refresh die stilletjes mislukt. Deze events triggeren geen statuspagina-updates omdat ze tijdelijk en lokaal zijn. Maar voor de job die om 06:00 gepland stond en om 06:01 een cluster nodig had, zijn ze dat niet.
De Free Edition maakt dit zichtbaar omdat er geen SLA is, geen gegarandeerde betrouwbaarheid en agressief quotumbeheer. Databricks-documentatie stelt ronduit dat Free Edition-accounts werken in een "serverless-only, quota-limited environment" waarbij het overschrijden van eerlijk gebruik de compute voor de rest van de dag uitschakelt. Maar het symptoom dat gebruikers rapporteerden was geen quotum-melding; het was een pagina die helemaal niet wilde laden. Dat onderscheid is belangrijk. Quotumhandhaving geeft een specifieke foutmelding. Een service-onderbreking geeft niets.
Geplande jobs mislukken stilletjes als het control plane onbereikbaar is
Databricks jobs worden georchestreerd via het control plane, de servicelaag die de cluster-lifecycle, job scheduling en API-requests beheert. Als het control plane gedegradeerd is, hangen de gevolgen af van het tijdstip.
Een job die al draait op een actief cluster kan zonder problemen doorgaan. De compute-resources zijn al geprovisioneerd; het data plane verwerkt de uitvoering onafhankelijk. Maar een job die tijdens de onderbreking zou starten, wordt nooit gestart. Er is standaard geen retry, tenzij je retry policies hebt geconfigureerd in de job-definitie. En zelfs dan vuurt de retry alleen als de eerste poging een failure heeft geregistreerd. Als de API-aanroep om de job te starten het control plane nooit heeft bereikt, is er niets om te herproberen.
Dit creëert een specifieke failure mode: een job run die niet bestaat. Geen mislukte run in de job-geschiedenis. Geen fout in de logs. De run heeft gewoon niet plaatsgevonden en het enige bewijs is de afwezigheid van een verwachte vermelding in de run-geschiedenis, of stale data in de doeltabel.
Voor teams die de Databricks REST API gebruiken via externe orchestrators zoals Azure Data Factory of Apache Airflow, manifesteert de failure zich anders. ADF's Web Activity die api/2.1/jobs/run-now aanroept, geeft een HTTP timeout of connection refused terug. Dat levert tenminste een pipeline failure op. Maar ADF's standaard retry-gedrag kan dit maskeren: drie retries met exponential backoff kunnen een uitval van 15 minuten stilletjes absorberen, waardoor het uiteindelijke succes er routinematig uitziet terwijl het verbergt dat de data 45 minuten te laat is aangekomen.
De Stack Overflow Developer Survey van 2024 laat zien dat Databricks SQL door 1,9% van alle respondenten wordt gebruikt. Dat cijfer onderschat de productie-impact. Databricks staat doorgaans in het midden van pipelines, niet aan de rand. Één workspace voedt tientallen downstream consumers. Één gemiste job heeft cascading effecten.
Downstream consumers erven de gap zonder het te weten
Als een Databricks job niet draait, bevatten de tabellen die hij had moeten bijwerken de data van gisteren. Elk systeem dat die tabellen leest, gaat gewoon door omdat de data geldig is. Ze is alleen stale.
Een Power BI dataset die om 07:00 gepland staat te refreshen, maakt verbinding met een Databricks SQL Warehouse, voert de queries uit en sluit succesvol af. Het refresh-logboek toont geen fouten. Het semantisch model wordt bijgewerkt. Dashboards renderen. Maar de cijfers zijn van gisteren, omdat de ETL-job die om 06:00 de brontabel had moeten refreshen, nooit is uitgevoerd. De Power BI refresh is geslaagd op stale data en de service heeft geen mechanisme om het verschil te zien.
Hetzelfde geldt voor dbt-modellen met een source freshness-check, maar alleen als je freshness-tests hebt gedefinieerd en ze ook daadwerkelijk uitvoert. Een dbt source freshness-commando controleert het loaded_at-veld aan de hand van verwachte intervallen. Als je warn_after: {count: 6, period: hour} hebt ingesteld en de bron is niet bijgewerkt, markeert dbt dat. De meeste teams configureren dit. Minder teams voeren het bij elke aanroep uit en nog minder sturen de waarschuwingen naar een plek die om 06:30 op een maandag zichtbaar is.
ADF-pipelines die afhankelijk zijn van Databricks notebook-activiteiten hebben hun eigen variant. Als de upstream Databricks pipeline is mislukt of nooit heeft gedraaid, kunnen ADF's Lookup- of Copy-activiteiten slagen op stale brondata of mislukken met een onverwacht schema als een delta-tabel een inconsistente checkpoint-staat heeft. De ADF-foutmelding in dat geval is doorgaans DeltaSourceException of een generieke UserError. Geen van beide wijst terug naar een gemiste upstream Databricks-run als root cause.
De gap tussen "het systeem werkt" en "de data is actueel" is precies waar stale dashboards wonen. Elk tool in de keten rapporteert groen. De data is een dag oud.
De afwezigheid van een run detecteren is moeilijker dan een failure detecteren
Standaard alerting vangt failures op. Een Databricks job die start en een exception gooit, produceert een run met result_state: FAILED. Je kunt daarop een alert instellen via native Databricks-notificaties, PagerDuty-webhooks of aangepaste polling op de Jobs API.
Maar een alert instellen op een run die nooit heeft plaatsgevonden, vraagt om een andere aanpak. Je moet weten wat had moeten draaien en dat vergelijken met wat daadwerkelijk heeft gedraaid. Dit is schedule-aware monitoring.
Het Databricks Jobs API-endpoint GET /api/2.1/jobs/runs/list geeft runs terug voor een bepaalde job. Als je dit na het verwachte uitvoeringsvenster pollt en geen run vindt met een start_time in het verwachte bereik, heb je de gap gedetecteerd. Maar het bouwen van deze polling-infrastructuur betekent het bijhouden van een register van verwachte schedules, rekening houden met tijdzones, DST-overgangen verwerken en bepalen wat "te laat" betekent voor elke job.
Sommige teams bouwen dit met een lichtgewicht Python-script op een cron:
import requests, time
JOB_ID = 12345
EXPECTED_WINDOW_START = int(time.time()) - 7200 # 2 hours ago
runs = requests.get(
f"{WORKSPACE_URL}/api/2.1/jobs/runs/list",
params={"job_id": JOB_ID, "start_time_from": EXPECTED_WINDOW_START * 1000},
headers={"Authorization": f"Bearer {TOKEN}"}
).json()
if not runs.get("runs"):
send_alert(f"Job {JOB_ID} has no runs in the last 2 hours")Dit werkt totdat je 200 jobs hebt verdeeld over 4 workspaces. Dan wordt het zijn eigen reliability-probleem. Een monitoring-script dat zelf bewaking nodig heeft.
MetricSign pakt dit anders aan door verwachte refresh-cadences bij te houden voor Databricks jobs, Power BI datasets en ADF-pipelines. Als een Databricks job geen run produceert binnen het verwachte venster, geeft MetricSign een refresh_delayed-signaal af en koppelt dit aan downstream consumers die nu op stale data draaien. De detectie is niet "is de job mislukt", maar "heeft de job überhaupt plaatsgevonden en wie is er getroffen".
De Free Edition maakt het probleem zichtbaar; productie maakt het duur
De Databricks Free Edition is een nuttige kanarie. De beperkingen ervan (geen SLA, throttling op basis van quota, mogelijk account-verwijdering na inactiviteit) maken service-onderbrekingen frequent genoeg dat gebruikers patronen herkennen. Het incident van 9 juni was geen op zichzelf staand geval; de Community-forums bevatten vergelijkbare meldingen verspreid over maanden, elk met hetzelfde verloop: plotse onbereikbaarheid, geen formeel incident, zelfoplossing binnen enkele uren.
Betaalde Databricks-workspaces hebben SLA's en dedicated compute, maar het control plane is gedeelde infrastructuur. Databricks publiceert uptime-doelstellingen, geen uptime-garanties, voor het control plane. Het data plane (waar je Spark-jobs daadwerkelijk worden uitgevoerd) draait op de compute van je cloud-account. Maar job scheduling, cluster provisioning en API-toegang lopen allemaal via Databricks-beheerde services.
Het praktische risico is niet langdurige uitval. Databricks is over het algemeen betrouwbaar. Het risico is het tijdvenster van drie uur waarin alles er goed uitziet, omdat geen enkel systeem is ontworpen om een gap op te merken. Je Airflow DAG heeft het na 40 minuten vertraging opnieuw geprobeerd en is geslaagd. Je Power BI refresh heeft de data van gisteren opgehaald en geen fout gerapporteerd. Je Slack-kanaal bleef stil omdat er technisch gezien niets is mislukt.
Drie uur later vraagt een finance director waarom het omzetdashboard op maandagochtend de cijfers van vrijdag toont. Het antwoord is een Databricks control plane-blip om 05:47 die om 08:30 was opgelost. Maar dan is de geloofwaardigheidschade al aangericht. Elk monitoring-tool zei groen. De data zei vrijdag.
Een freshness-first alerting-laag bouwen
Freshness monitoring vereist drie componenten: een schedule-register, een statusvergelijkingslus en een dependency map.
Het schedule-register definieert wat er moet gebeuren en wanneer. Voor Databricks jobs is dit de cron-expressie in de job-definitie, op te vragen via GET /api/2.1/jobs/get onder settings.schedule. Voor ADF-pipelines is het de trigger-definitie. Voor Power BI is het het refresh-schema van de dataset in de workspace-instellingen. Dit alles samenvoegen in één overzicht is de eerste stap.
De statusvergelijkingslus vergelijkt de werkelijke uitvoering met de verwachte uitvoering. Poll voor Databricks runs/list en controleer of er een succesvolle run bestaat in het verwachte venster. Poll voor ADF de Monitor API voor pipeline runs. Gebruik voor Power BI het GET /groups/{group_id}/datasets/{dataset_id}/refreshes REST-endpoint om de meest recente refresh-tijdstempel te controleren.
De dependency map verbindt deze checks. Als Databricks job A tabel X voedt en Power BI dataset B tabel X leest, moet een gemiste run van job A een alert genereren die zowel de gemiste job als de betreffende dataset benoemt. Zonder deze mapping krijg je twee afzonderlijke alerts met uren tussentijd: één voor de gemiste Databricks job (als je die detecteert) en één voor stale Power BI data (als iemand dat opmerkt). Met de mapping krijg je om 06:15 één alert: "Job A heeft niet gedraaid. De volgende refresh van dataset B om 07:00 zal stale data ophalen."
Dit is haalbaar met eigen tooling. Een combinatie van Azure Functions die elke API pollt, een metadata-opslag in een SQL-database en een notificatielaag kan dit afdekken. Reken op 2 tot 3 weken engineering-tijd voor een robuuste implementatie over één Databricks-workspace en zijn downstream consumers. Dat vermenigvuldigt voor elke extra workspace, cloud-regio of BI-tool in je stack. De build-versus-buy-afweging hangt af van hoeveel gaps van 05:47 je kunt absorberen voordat iemand vraagt waarom het dashboard foute cijfers toont.