How status is determined
The status shown for each shared service of the Velocity Interoperability Network is the result of a fixed procedure. The same procedure applies to every service and is carried out by the Status Service rather than by the office responsible for the service. This page describes the procedure in full: the cycle of checks that runs at all times, what each check requests, what happens when a check fails, how a fault reported by an office is handled, and how a new service is brought under monitoring.
The check cycle. The five steps below are repeated every fifteen minutes for every service. All times shown on this site are those of the scheduled checks, in the standard time of the Network.
Step 1: Automated check
Every fifteen minutes each shared service is requested from within the Network. The check records whether the service responds, how long it takes and whether the response is complete. Each component of a service is checked separately, and the results are retained.
Step 2: Comparison with the expected result
The recorded response is compared with the result expected for that service. A response that is correct and timely is recorded as Operational; a slow or partial response as Degraded; no response as Unavailable.
Step 3: Confirmation by the responsible office
Any change from Operational is referred to the office responsible for the service, which confirms the change or reports that it was caused by the check itself.
Step 4: Publication
The confirmed status is published on the home page together with the time of the check. Where a service is Degraded or Unavailable, an incident is opened.
Step 5: Record of the incident
The incident is updated as the cause is identified and resolved, and remains on the Incidents page once closed.
What each check requests. A check is not a simple request for a response; it exercises the service in the way a member organisation would, using test accounts and entries created for the purpose. The table below summarises the request made to each service, the response expected and the time within which it must arrive. The time limits are those set by the service levels.
| Service | Request | Expected response | Time limit |
|---|---|---|---|
| Identity Service | Sign in with a test account and verify the token issued | A valid token for the test account | 2 seconds |
| Member Registry | Retrieve a fixed test entry and run a search returning it | The entry, and a search result containing it | 3 seconds |
| Developer Portal interfaces | Call each published interface with a test credential | A well-formed response from every interface | 2 seconds |
| Official Register | Retrieve a fixed test entry and request a certified extract of it | The entry and a correctly signed extract | 3 seconds |
| Support desk | Retrieve a fixed test request and display its progress | The request with its current progress | 5 seconds |
| Interoperability exchange | Send a test message to the Status Service and await its acknowledgement and delivery | An acknowledgement within the time limit and delivery within five minutes | 1 second to acknowledge |
Status definitions. Four statuses are used on this site. The first three are the possible results of a check; the fourth is set by the Status Service for the duration of an announced maintenance window and is not the result of a check.
| Status | Meaning | Action |
|---|---|---|
| Operational | The service responds correctly within the expected time. | None. |
| Degraded | The service responds, but more slowly or less completely than expected. | An incident is opened and the responsible office is notified. |
| Unavailable | The service does not respond to the check. | An incident is opened and the responsible office is notified at once. |
| Maintenance | The service, or a component of it, has been deliberately withdrawn during a window announced on the Scheduled maintenance page. | No incident is opened. Checks continue, and a fault unrelated to the announced work is treated as an incident. |
When a check fails. A single failed check does not by itself change the status of a service. The steps below are followed whenever a scheduled check records a result other than Operational.
Step 1: Repeat the check
A check that fails is repeated at once from a second point within the Network. If the repeat succeeds, the original failure is recorded but no change of status is made; two such failures in succession are treated as a genuine change.
Step 2: Classify the result
A confirmed failure is classified as Degraded where the service responded slowly or partially, and as Unavailable where it did not respond. Where more than one component failed, the service takes the more serious classification.
Step 3: Notify the responsible office
The office responsible for the service is notified by email with the time of the check, the components affected and the response recorded. The time of notification starts the clock for the response times on the Service levels page.
Step 4: Open the incident
An incident is opened with the next reference in sequence, the status is changed on the home page and the Component status page, and the first entry is made in the incident log.
Step 5: Update the log
The responsible office adds an entry at each of the intervals set out on the Service levels page, or sooner where there is something to report. Each entry is timed and attributed to the office that made it.
Step 6: Confirm restoration and close
When a scheduled check records the service as Operational and the responsible office confirms that the cause has been removed, the incident is closed. The time of the confirming check is recorded as the end of the interruption.
Faults reported before a check. Fifteen minutes is long enough for a fault to be noticed by an office before the next scheduled check finds it. The interruption of 6 September 2026 was reported in this way: the Identity Service office reported failures of sign-in at 08:20, ten minutes before the check at 08:30 recorded the service Unavailable. Reported faults are handled as follows.
Step 1: Report received
A responsible office may report a fault directly to the Status Service at any time, without waiting for the next scheduled check. The Support desk of a member organisation may do the same where it has confirmed that a fault affects the shared service rather than a single connection.
Step 2: Check brought forward
The Status Service carries out an immediate check of the service and its components. If the check confirms the fault, the procedure for a failed check is followed from that point, and the time of the report is recorded as the start of the interruption.
Step 3: Report not confirmed
If the immediate check finds the service Operational, the report is recorded but no incident is opened. The service is checked again after five minutes. A report that is confirmed on the second check opens an incident dated from the original report.
Bringing a new service under monitoring. The six shared services were brought under monitoring together at 08:00 on 6 September 2026. A service added to the Network after that date passes through the steps below before its status is published.
Step 1: Agreement of the components
The responsible office and the Status Service agree the list of components into which the service is divided for the purposes of this site, and the description of each.
Step 2: Definition of the check
For each component, the office provides a test request, the expected response and the time within which it should be returned. Test accounts and entries are created for the purpose and are not used for anything else.
Step 3: Trial period
The checks are run for at least five working days without publication, and their results are reviewed with the office to confirm that the expected responses are correct and that no check disturbs the service.
Step 4: Publication
The service and its components are added to the home page and the Component status page, its service levels are published, and the date from which its record begins is noted on the Availability reports page.
Limits of the method. Checks are made from within the Network and measure the shared services as they present themselves to a correctly connected member organisation. They do not measure the connection of any particular organisation, and a service shown as Operational may still be unreachable from a site whose own connection has failed. Nor do checks exercise every function of a service; they exercise the functions on which the other shared services and the member organisations most depend. A fault in a function that is not checked is discovered when it is reported, and is then handled as a reported fault.
The interval between checks, the expected results and the offices responsible for each service are reviewed by the Status Service whenever a shared service is added or changed, and at the quarterly review described on the Availability reports page. The present status of every component is shown on the Component status page; the record of every incident on the Incidents page. Questions about the method may be sent to contact@status.gov.vin.