Loading status

The status page monitors whether new content is still being received by the source platforms. This is a different question from whether a platform is responding. These two issues are unrelated: a platform may be perfectly accessible yet have not received any new content for months. To check the availability of BesluitBron itself, visit /health, listed in the footer as ‘Health’.

Each language version of the page has its own URL

From version 1.3.36 onwards, the page has a separate address for each language: /nl/status, /en/status, /de/status and /fr/status. The address /status continues to work. It no longer displays anything itself, but redirects to the language the visitor previously selected or the one requested by the browser. An existing link to /status will therefore still lead to the page.

Up to and including version 1.3.35, only /status existed, and that page was always in Dutch, regardless of the language the visitor had selected.

The text now adapts to the reader’s language. This also applies to the sentences being analysed, such as “iBabs has not delivered anything since 5 August”. The page is available in four languages: Dutch, English, German and French. In the twelve other languages supported by the site, the page is in Dutch.

Two things have been left untranslated, deliberately:

• the name of a source, of an administrative body and of a source system. These are proper names, and a reader must be able to look them up at the source itself;
• a field name or a raw value from a platform, such as harvest_age_seconds, and the text of an error message. These are shown exactly as the platform wrote them, so that a reader can quote them.

A monitoring system that retrieves /api/status.json without specifying a language preference will be set to Dutch, as before.

Four states, and why there aren’t three

• laadt: new material is coming in, at the pace this source is supposed to maintain;
• traag: lagging behind at her own pace, but still moving;
• stil: long enough without any news to call this a glitch, and not a quiet week;
• gesloten: deliberately no longer updated. Open Archivaris was deliberately discontinued in July 2021. Displaying that source permanently in red would teach the reader to ignore any red text on the page.

In addition, there is ‘onbekend’, which refers to a measurement that has failed or has not yet been carried out. This is explicitly not meant to be reassuring: a failed measurement does not constitute a reliable source.

The thresholds are specified for each source and have been measured

A single fixed threshold applied across all sources would be meaningless. The Tweede Kamer publishes nothing on weekdays or at weekends. OpenTK is a few minutes behind. At Rechtspraak, publication is, by its very nature, months behind the court hearing. Each source therefore has its own expected rhythm and its own threshold, which are shown on the page alongside the assessment.

The thresholds as they currently stand:

For the two local sources, the assessment is based on the average publication rather than the most recent item in the index. A single new document from three hundred publications would otherwise turn the entire source green, whilst the publication the reader enquired about has been inactive for weeks.

Two questions per body, and the worst one counts

On OpenBesluitvorming, since version 1.3.23, two ratings have been displayed side by side, and the lower of the two determines the colour:

• Does the platform still collect data from this body? The platform itself reports this, on a body-by-body basis;
• Is the date it was retrieved still recent? That’s the date of the most recent article.

Those two figures can diverge in any direction, and it is precisely that difference that constitutes the useful information. An import that runs flawlessly for a committee that hasn’t met since the spring is not ‘in order’. Nor is an index that appears up to date whilst the supply stalled last week. Averaging the two figures would simply take the interesting part out of it.

Where the platform’s report and our own observations contradict each other, this is stated as a sentence on the page. This was evident in August 2026: the platform reported a disruption, whilst the average body remained within the threshold, as the summer recess does not count and the disruption began during the recess.

What the source itself says about a dormant organ

From version 1.3.91 onwards, next to each body that has ceased operations, there is a note stating what the source reports about it, insofar as it reports anything at all. That is the only thing a reader cannot deduce from the date shown alongside it, and it shifts the cessation of operations from a reproach to a fact.

Next to each body, there is also a link to that source’s explorer. From version 1.3.91 onwards, this link does not open the tile list but takes you straight to the relevant tool, with the query for that body already filled in: the latest items that the platform has for that body. The query is contained in an editable field, so selecting a different time period or document type requires just one simple adjustment. This can be done without logging in; visitors share a single query per second with all other visitors.

The ruling is shown as a letter in the table, with the sentence above it in a legend. Eighteen of the twenty-three organs shared the same eighty-character sentence, and repeating this on each line took up the width of every other column. Two organs with the same sentence spanning a different period are assigned two letters: these represent two different rulings.

Three types of rulings, listed in order of how much detail they provide:

• the error message from the platform itself, quoted verbatim. On 13 September 2026, this concerned four bodies: for two of them, the platform displays the message ‘No public account!’, which means that the documents are not publicly available anywhere, and for the other two, there is a time limit on the platform’s own import function;
• The supplier did not mention a single item over the past year. In that case, there is nothing to collect, and the hold-up lies at source, not with the harvest. This applied to eighteen organs;
• The platform contains everything the supplier mentioned over the past year, whilst the date next to it is older. These are two rulings that cannot both be correct, and the page points this out rather than asking you to choose one yourself.

Open Raadsinformatie From this version onwards, it no longer contributes any entries to this list. That platform is being phased out, and OpenBesluitvorming retrieves the same bodies from the same four source systems; consequently, each body appeared twice: sixteen of the thirty-nine entries were duplicate mentions of a municipality that had already listed its successor. The bodies from that platform are still being measured and are included in the map of that source itself; only the list per body has been removed.

Eleven bodies have been removed from the list since this version. Their most recent date was a scheduled meeting, which meant that BesluitBron did not know the most recent date recorded and, for lack of evidence, classified the body as ‘unknown’. The weekly comparison does, however, provide that evidence: a body that retains what the supplier reported for the past year will have received documents in that year. One of those eleven had 22,993 documents, a successful import that very morning and 2,423 out of 2,423 documents for the year; the only thing missing was a meeting in December on the agenda.

Sorting and grouping

From version 1.3.91 onwards, both tables can be sorted by column: click on a column header, and click again to reverse the order. An empty value always appears at the bottom, regardless of the sort order of the column: ‘no produce harvested’ is not the smallest value in a column; it is the absence of a value. Without JavaScript, both tables retain the order in which they are constructed, which is the most useful: the most severe cases at the top in the completeness table, and by name in the list of inactive organs.

Both tables are grouped by source, with the name of the source appearing above the table rather than in a column. At present, there is only one group, as only one source publishes these figures. Should a second source begin to do so, it will be given its own heading and its own table.

Incomplete is not the same as stagnant

From version 1.3.91 onwards, there is a second table at OpenBesluitvorming: bodies for which the platform itself states that documents are missing. This is a different matter from the rest of this page. Elsewhere, you can see how RECENT a harvest is; here, it shows how much of that harvest is missing.

A database can be updated every night and still be missing items. A search won’t reveal this: anything that has never been entered leaves no trace to search for. Only the platform can compare itself with the database provider, and it does so every week for the past year.

On 13 September 2026, 155 of the 330 bodies compared were missing something. For most, this involved a handful of items; in the case of one water authority, the supplier reported 311 items over the past year, whilst the platform had recorded 8, even though the import process was successful every night.

The columns are called “Reported” (the figure provided by that organ’s supplier) and “Found” (the figure recorded by the platform). The percentage missing is given in parts per thousand: the two counts are taken at different times, and for nine organs, the supplier’s own figure is a lower limit, so a decimal place would indicate a level of accuracy that nobody has measured.

Where an entry contained the word ‘at least’, the platform was unable to read the supplier’s list in full. The figure provided by the supplier is therefore a lower limit, as is the number of missing items. The table shows the platform’s findings and does not indicate the cause.

The billing system behind a fault

OpenBesluitvorming It specifies, for each body, which source system underpins it, and also details, for each source system, how the import process went. This makes it possible to attribute a fault to a party that is able to rectify it. Four source systems collectively support all the bodies, so a single system that stops supplying data affects a third of the country.

On 16 August 2026, 161 of the 330 bodies were down for one reason: since 5 August, iBabs had been blocking the address from which the platform retrieves data. Without that breakdown, the page would have shown 161 individual municipalities that just happened to be silent at the same time.

The details show, for each source system, how many services it supports, how many import runs were successful, when the last successful run took place, and what message the platform displays in that instance. In the event of a fault, ‘last successful run’ indicates exactly how long the fault has been ongoing.

The assessment of a delivery system is based not only on the platform’s statement, but also on the figures it provides. If the platform retrieves fewer than nine out of ten components of a system, the delivery is deemed faulty, regardless of the wording used. That threshold is set at 90 per cent, because a body that is not included is a council whose documents do not arrive, and sixteen such councils is not merely a rounding error. A system that reports a problem but does deliver data from nine out of ten bodies is classified as ‘traag’. A word not recognised by BesluitBron is classified as ‘onbekend’, as it could also mean ‘maintenance’; such a word does appear in the trace, so it stands out.

This has been the case since version 1.3.41, and the reason is set out in the figures for 17 August 2026. On that day, the platform reported the blocking of iBabs as degraded instead of down, because one of the 167 import runs had been successful, whilst 160 of the 161 bodies received nothing. Up to and including version 1.3.40, BesluitBron only looked for that specific word: the source turned grey, the error message disappeared from the header and the bar at the top of the page no longer mentioned iBabs – simply because the platform had chosen a different word.

In the case of a system that is no longer delivering anything at all, the date on which it last worked successfully is shown, as that is exactly how long the fault has lasted. In other cases, that date is not shown: a single successful run today would otherwise be interpreted as a fault that began today. The figures are shown there, indicating how many organs are not being retrieved. Those figures also appear in the bar at the top of the page, and for the same reason: the same threshold applies to a system that misses a sixth of its predictions and a system that no longer retrieves any at all, and those two situations must not be interpreted in the same way.

A scheduled meeting is not a completed task

An agenda is published before the meeting, so the most recent date for a body is often in the future. Such a date does not count as the most recent item: otherwise, a body whose term ended in 2021 would be described as ‘current until 2027’ simply because a meeting was once scheduled far in advance.

However, the date does not disappear. Where a body has only a scheduled meeting, that date is listed separately. ‘None’ would suggest a council meeting without any agenda items, even though a meeting is due to take place next week. A meeting within three weeks serves as proof that the body is active, as that agenda cannot have been published long ago. A meeting further in the future says nothing about this month and results in onbekend, never laadt.

When the page turns red

In addition to the assessment for each source, there are two rules that cause the headline to turn red:

• if, at a single source, 50 or more organs are at a standstill, or if one-tenth or more of the organs are at a standstill. That second rule applies to a source system comprising fewer than 50 organs: if such a system fails, this constitutes a fault affecting a single owner, whilst the average organ remains operational;
• BesluitBron is itself unable to respond to calls. That reason takes precedence over all others: pointing the finger at seven third parties whilst its own tools are failing is inappropriate.

The rule counts the judgements per body, and therefore does not take dates into account itself. Consequently, the same thresholds and the same recess apply to the header as to the rest of the page. A component expected to be inactive is not counted, nor is it included in the total against which the proportion is measured. A component with the status ‘onbekend’ is also not counted: this indicates a measurement that failed, not a component that is inactive.

Up to and including version 1.3.40, a different rule applied: 50 or more councils with a most recent entry more than 3 calendar days old, or one council with an entry more than 10 calendar days old. That rule contradicted the rest of the page. On 17 August 2026, it was true for 317 of the 320 bodies listed on Open Raadsinformatie, because virtually no council met in August, whilst that same page showed 302 of those bodies as ‘laadt’ and the source itself was simply adding new material. The headline therefore highlighted a body that contradicted its own table. The row containing a single body has been removed entirely: a body that has been inactive for years – such as Flevoland since 22 December 2021 – is not a current fault, and a heading that remains red for this reason teaches readers to ignore any red text. Such an organ is listed in the list of inactive organs. From version 1.3.41 onwards.

Whatever makes the page red is stated in a sentence. A red dot that a reader cannot make sense of is a red dot that one learns to ignore.

When the light is red, there is a bar at the top of every page

If the header is red, a red bar appears at the top of every page on the site, directly below the menu bar. This bar explains what is currently on hold, and the bar itself is a link to this page. This way, a visitor who came for something else will also be made aware of it. From version 1.3.41 onwards.

The bar states the cause as precisely as the measurement allows:

• the data system behind a data source, if the platform itself reports that the data from that system is incorrect, specifying the figures. For example: “iBabs on OpenBesluitvorming.nl has not been synchronising 160 out of 161 bodies for some time now”;
• the source itself, if the platform does not report anything by Rechtspraak system. For example: “Rechtspraak has not been synchronised for some time”;
• a fault with BesluitBron itself, if the tool fails in this respect. This reason takes precedence over all others;
• the sentence that makes the headline turn red, when no source is standing still and has ticked the rule from the previous chapter.

A source system is only mentioned if the platform itself reports it. That name then appears on every page of the site, and this is only permitted with the platform’s authorisation. Drawing one’s own conclusions from the dates provided by each organisation does not constitute such an indication: a system that ceased operations last week leaves behind organisations whose most recent entry still falls within the threshold.

The bar isn’t on this page itself, as the page explains the same thing in more detail. There’s nothing under ‘orange’ either. A bar that’s there half the time is a bar that nobody reads anymore.

Up to and including version 1.3.53, the bar did not appear in the documentation. Those pages have their own layout, and the bar was not included in that layout. Anyone who accessed the documentation via a search result would therefore not have found any mention of a static source there. From version 1.3.54 onwards, the bar appears on every page of the documentation, including the search page.

Organs expected to cease functioning

Both local sources provide access to the archives of disbanded municipalities. Such an index remains static without anything being broken. On 16 August 2026, Open Raadsinformatie identified ten of the approximately thirty inactive bodies, representing one third of the data set.

Such organs are not taken into account in the standstill and are not included in the list of organs subject to the standstill. There are two reasons why a standstill might be expected, and both are listed alongside the organ:

• the organisation has been dissolved, usually as a result of a local authority reorganisation;
• The source has deliberately stopped referencing the publication, although the content remains searchable.

The source of this information varies depending on the source. In the case of Open Raadsinformatie, the list is based on the Register of Public Organisations as at a specific reference date and is not updated continuously; consequently, a municipality that was subsequently amalgamated is missing from the list; these bodies are therefore marked with the word ‘possible’. On OpenBesluitvorming, the platform reports this information itself, for each body, stating the date of dissolution and the name of the successor.

Sourcing system by organisation

In practice, the council information system used by a local authority determines who can rectify a failed data submission. This question cannot be answered by consulting a list of suppliers, as no one publishes such a list. However, the question can be resolved by counting. The web archive recorded, for each document, which system the data extraction tool communicated with. The addresses from which the files originated therefore provide the answer.

Of the 327 organisations, the system can be broken down as follows: 158 use Notubiz, 142 use iBabs and 27 use GemeenteOplossingen. For each organisation, the percentage of its documents originating from that system is specified, as ‘100 per cent’ and ‘29 per cent’ are rulings of varying strength.

The restriction is stated on the page itself and is important. The data collection ran from 6 October 2020 to 30 July 2021 and ceased thereafter. This therefore reflects what an organisation was doing at that time. A municipality that has since switched systems is still listed under the system it left, and it is not possible to tell from this data which municipalities are involved. Out of 302 organisations, the data harvest only retrieved the website. Whilst the archive does show the documents, it does not indicate which system published them.

This count was carried out once and is recorded in the publication. The archive from which it is taken has been closed, so the result cannot change. Asking a question with a fixed answer over and over again would only slow the page down.

How often measurements are taken

All sources are re-measured every eight hours, and each measurement takes one call. The first measurement runs shortly after start-up. Until it is complete, the page reports that no measurement has yet been taken, rather than displaying a blank page that would appear to show that many inactive sources.

After start-up, it takes about 25 seconds for all the figures to appear, 20 seconds of which are spent waiting deliberately: the start-up process is already communicating with various platforms, and adding seven measurements on top of that straight away would make the busiest second of the process even busier.

Up to and including version 1.3.22, this did not apply to OpenBesluitvorming. That platform did not provide an overview of all organs, so checking the status of each organ required a separate request, and a full round took well over three hundred. That cycle was spread over four hours, one organ at a time, to avoid causing a peak load on the platform. Since version 1.3.23, the platform has been publishing its own status for all organs in a single request, and that detour is no longer necessary. As a result, a complete table is available after 25 seconds instead of four hours.

More important than the time saved is the fact that the table now represents a single snapshot. With the spread-out round, each figure was measured at a different time, so an organ from 06:00 was listed alongside one from 09:45. All organ readings now come from the same measurement taken by the platform, and that time is stated in the supporting evidence.

An assistant can request this measurement themselves

From version 1.3.36 onwards, each connector includes the ‘platform_status’ tool. This provides the same measurements as this page, but in the form of data: for each source, the status, the time of measurement, whether the platform itself provides any information about its loading process, and whether that ruling differs from what BesluitBron observes. For the two local sources, this is supplemented by the numbers per status, the date of the most recent entry and, at most, ten inactive bodies with the date on which their data ceased. The full report for each body remains on this page, and the response provides its address.

The tool is designed for a single question that a search result cannot answer. An empty result means nothing in itself: it may be that nobody discussed the topic, or it may be that the source has not received any new information for weeks. An assistant using this tool can determine which of the two is the case and up to what date the material is current.

Everything can be viewed and downloaded

When you hover over or focus on any source, the supporting evidence is displayed: the method, the raw figures, the threshold that led to the assessment, and the time of measurement. In addition, the ‘Download report’ option provides all the figures from a single measurement as Markdown, including the table for each organ. For a monitoring system, the same content is available at /api/status.json; see Statusgegevens.

From version 1.3.36 onwards, the organs are listed by name, both in the list on the page and in the report. Up to and including version 1.3.35, the organ with the oldest material appeared at the top. A reader looks up a single organ here – usually their own – and in a list of nearly two hundred names, this can only be found if the list is sorted by name. The date is shown in a separate column, so anyone who wants the oldest organ at the top can sort that column in a spreadsheet.

From version 1.3.36 onwards, the Markdown report for each source has a separate URL for each language, for example /de/status/ori.md. The page links to that URL, which includes the language. This is intentional: the language in the URL is the one the visitor selected, whereas a browser’s language preference is something that someone else set at some point. The URL without the language, /status/<bron>.md, remains in use and continues to respond: it selects the language based on the requester’s preference and does not redirect. A monitoring system is often a script that does not use cookies and does not follow redirects, and it is precisely this type of requester that must not encounter any issues here.

/api/status.json has changed the way it specifies the language, as the address has been /api since version 1.3.86: a query parameter instead of a path for each language, and up to and including which version it was located in its old place. Both are listed at Statusgegevens.

Every sentence in the JSON contains a code

At /api/status.json, behind every sentence a person reads, there is also the message code. The field at _label contains the text and changes depending on the language. The field at _code describes what is written and remains the same in every language. A monitoring rule should check the code.

For example, state_label appears alongside state_code with “stil” and Stalled, and cadence_label alongside cadence_code. In the justification, each row contains a label_code and a value_code. red_reason_code is the clearest example: it indicates which of the three lines caused the page to be marked red, and this can be deduced from the sentence alone.

state_code is the only code that is not a message code. A state is a fixed value rather than a string, so it contains the name of the state itself. These names are in English, because a name in code is always in English here:

The tool platform_status uses the same five words, in lower case: loading, slow, stalled, closed and unknown.

Up to and including version 1.3.35, these fields were named state, cadence, threshold, headline, group, worst_state, bodies_note and standstill_reason; they were only available in Dutch and did not have any codes. Anyone using these names should update them when upgrading to 1.3.36.

An organ may have stopped functioning because the board did not meet, because the supplier has stopped delivering, or because the harvest has been ruined. The page shows the observation but does not indicate the cause.