Planned and unplanned downtime

Code of connection

The code of connection sets out how pension providers, schemes and integrated service providers (ISPs) need to manage planned and unplanned downtime activities. As stated in the code of connection, the points related to downtime are as follows:

• CoCo2.1.4 – Must target restoring service within 2 hours in the event of an endpoint outage, without loss of data ACKed before the outage.
• CoCo2.1.5 – Must target availability of at least 99.5%, 24/7, measured by calendar month. For clarity, 99.5% availability means 0.5% unavailability for whatever reason.
• CoCo2.2.1 – Must give a minimum of 5 working days’ notice to MaPS in advance of a scheduled service unavailability. Service unavailability includes any gap in service due to the service being unavailable or impaired.
• CoCo2.2.2 – Must notify MaPS (through the connecting organisation, not directly from pension provider or scheme to MaPS, if connecting via a third party) as soon as possible of any change in connection arrangements. This includes changes ‘internal’ to the connection solution used, such as moving from a data lake ISP model for processing of find or view requests to using a federated model with onward connectivity between ISP and provider or scheme.

Planned downtime

Planned downtime refers to scheduled periods when a system, product or service is intentionally taken offline for maintenance, upgrades, or other necessary tasks.

Change windows

To minimise the impact on citizens, MaPS recommend that all connected organisations conduct any planned downtime to the pensions dashboards ecosystem during the following change windows. This applies to pension providers or schemes or administrators utilising ‘distributed’ or ‘federated’ third-party connection solutions. These solutions are where there is onward connectivity between the third-party system connecting to the ecosystem and the pension provider/scheme/administrator system which receives find/view requests, as opposed to a data lake at the third-party connection provider where matching is undertaken/from which view data is returned:

• Day: Tuesday
• Time: 00:00am to 10:00am UK time
• Frequency: First and third weeks of the month

Connected organisations and schemes can select any change window to conduct planned downtime. However, it is the responsibility of the connected organisation to monitor downtime allowance to target 99.5% uptime per month.

Change freeze periods:

• New Year: 31 December, 1 January, 2 January
• Christmas period: 24 December to 30 December

Submitting notifications

Pension providers and schemes are required to tell MaPS about any planned downtime at least 5 working days in advance as stated in the code of connection. This can be done by any team member of a connected organisation with access to the technical support portal (typically primary business contacts and primary technical contacts). Connected organisations should provide holdername GUIDs of the affected schemes to give a comprehensive picture of the downtime.

To do this, connected organisations will be able to submit their notifications through the technical support portal by following these steps:

1. Login to the technical support portal
2. Select ‘Planned downtime notification’ on the main portal page.
3. Add the following information:
   1. organisation information
   2. scheme names (holdername GUIDs of affected schemes added as a spreadsheet)
   3. change window date
   4. expected start and end times
   5. reason for planned downtime activity

Amending or cancelling notification

If a connected organisation needs to change its plans after submitting a notification, this can be done by adding a comment to their original technical support portal ticket.

• Change of date: State that a new date is required and request that MaPS close this ticket, then submit a new ‘Planned downtime notification’ that includes the correct details.
• Cancellation: State that they need to cancel their downtime and request MaPS to close the ticket.
• Change of information: Add the updated information (for example, change to start and end time).
• Any other amendment: Add a comment to the ticket and await response from MaPS.

Conducting planned downtime

During the change window, the following steps should be followed:

1. MaPS inform user testing of planned downtime activities ahead of time.
2. Connected organisations begin downtime activities during the change window.
3. Connected organisations comment that downtime has been completed on the ‘Planned downtime notification’ ticket through the technical support portal, including the start and end times of the downtime. If no response is provided, MaPS will comment on the ticket to check the status of the planned downtime activity.
4. MaPS close ticket in the technical support portal.

In future, once user testing has been completed, MaPS will also look to implement user messaging and shuttering during downtime periods based on monitoring capabilities.

Issues during downtime

If more time is required than expected, connected organisations should let MaPS know through the comments on the planned downtime notification ticket. They will need to specify the issues and an expected timeframe for resolution.

Report an incident (unplanned downtime)

Connected organisations should report an incident when a system, product, service or pension data becomes unavailable to its users due to unforeseen issues (for example, software bugs or cyberattacks). Since these incidents lead to unplanned downtime, they require immediate attention. For the duration of private beta, this should be completed in real time to ensure that any incident doesn’t negatively impact private beta testing.

How to report

Connected organisations need to notify MaPS as soon as they become aware that an unexpected outage has occurred on their service or on a federated service – even if an incident is resolved quickly. This notification should provide a holdername GUID level of the affected schemes to provide a comprehensive picture of the incident. This can be done by any team member with access to the technical support portal (typically primary business contacts and primary technical contacts) and is required even when the downtime is short and/or already completed.

Connected organisations can submit these through the technical support portal by following these steps:

1. Login to the technical support portal
2. Select ‘Report an incident’ on the main portal page.
3. Input the following information:
   1. organisation information
   2. incident location (if the outage relates to MaPS instead of a connected organisation)
   3. affected scheme names (holdername GUIDs added as spreadsheet)
   4. status of incident
   5. estimated start time of incident and time of next update
   6. reason for downtime

Incident management

1. MaPS informs stakeholders (for example, users conducting testing).
2. Connected organisations update MaPS (through the original technical support portal ticket) on progress to resolve the outage.
3. Connected organisations inform MaPS when the service has been restored.
4. MaPS provides updates to stakeholders.
5. MaPS closes the incident ticket on the technical support portal.

Emergency fixes

If a connected organisation identifies a vulnerability with their service (for example, a security issue) that requires fixing as soon as possible, this should be covered under a connected organisation’s internal processes as outline in their service acceptance submission. Connected organisations should submit an incident report when the fix occurs.

Connected organisations need to:

1. Identify vulnerability.
2. Plan how to resolve it.
3. Submit an incident report.
4. Clearly state the reasoning for the emergency planned activity.

MaPS downtime

Planned downtime

In the case of any MaPS downtime, connected organisations can expect to be informed ahead of time regarding any planned downtime activities. These will cover various parts of the ecosystem (for example, the Salesforce connection portal or the Finder service) and occasionally will cover multiple areas. Connected organisations can expect to receive this information through the agreed communication channels:

• Email: [email protected]
• Day: Friday
• Frequency: The support emails are weekly, but the downtime information will be included as and when required.

Additionally, when downtime is active, this information will be provided as service updates in both Jira and technical support portals for your information.

During MaPS downtime, there is no action required from connected organisations unless otherwise stated in the planned downtime communication. Do not ‘take the opportunity’ while MaPS is conducting changes to pursue downtime as MaPS will be looking to validate our changes against the wider ecosystem.

MaPS incidents

MaPS will notify connected organisations as soon as possible of any incident related to the MaPS infrastructure. In these cases, MaPS will typically:

1. Email connected organisations and dashboard providers with details of the incident.
2. Put an update on the Jira portal.
3. Send follow-up emails / updated as more information becomes available.
4. Send a final email when the service has been restored and remove the Jira updates.

Unnoticed incidents

If a connected organisation identifies an incident on the MaPS infrastructure that is not connected to their own build, they should raise a ticket through the ‘Report an incident’ function on the technical support portal.

Support

Changelog

Last updated:15/05/2026