We use cookies to collect anonymous data to help us improve your site browsing experience.

Click 'Accept all cookies' to agree to all cookies that collect anonymous data. To only allow the cookies that make the site work, click 'Use essential cookies only.' Visit 'Set cookie preferences' to control specific cookies.

Set cookie preferences

Your cookie preferences have been saved. You can change your cookie settings at any time.

Operate a reliable service

A reliable digital service works for users whenever they need it. You must plan, design, and run your service to maintain uptime and availability according to the Digital Scotland Service Standard.

Why reliability matters

Reliable services build trust with users. If your service is often unavailable, users cannot complete tasks, which can reduce public confidence. Reliability is part of good service design and ongoing operation.

Design to maximise uptime

Design your service so it keeps working if parts fail or if demand increases. To do this, plan for reliability, resilience, and scalability. For example:

  • keep key components running when other parts fail

  • provide a read-only mode so users can view information when they cannot make changes

  • avoid single points of failure, including relying on one vendor

  • use multiple instances or nodes and spread traffic to reduce the impact of outages

  • consider Software as a Service (SaaS) solutions if they meet your requirements

  • distribute data and queries across database clusters to reduce the risk of crashes

  • queue data from third-party services and process it later if they go down

Understand what affects uptime

Your service will likely depend on other systems and suppliers. List all these dependencies, including any your suppliers rely on. Check the uptime you’ve agreed with them in their service level agreements (SLAs).

Underlying infrastructure

Your service might depend on multiple systems and suppliers. You may not manage all of them directly, which makes reliability more complex.

For example, if your application is maintained by your development team but relies on a database run by another team, that database might sit on infrastructure provided under a commercial contract. That infrastructure depends on utilities like power and network connectivity that you do not control.

Scheduled maintenance

Some services don’t count pre-arranged maintenance periods as downtime.

For example, a service could claim 100% uptime even though it shuts down every Monday evening for maintenance.

You shouldn’t hide uptime problems behind multiple maintenance periods. You can classify downtime as planned (scheduled maintenance) or unplanned (other problems), if your service genuinely needs scheduled maintenance.

Suppliers and contracts

Supplier contracts can affect your service’s reliability. Check terms carefully, including:

  • service level agreements (SLAs)

  • uptime guarantees

If a supplier regularly fails to meet these commitments, consider whether their compensation (credits or refunds) offsets the impact on users. Persistent problems may indicate the need to review your supplier choice.

Provide out-of-hours support

If your service fails outside normal office hours, like evenings and weekends, it will be down for a long time unless you have someone responsible for out-of-hours support.

Research whether users access your service during evenings or weekends. If they do, decide whether providing out-of-hours support is worth the cost and whether you can secure the budget.

If you choose to provide support:

  • assign someone on call for issues
  • provide dedicated 24/7 support if needed

Tell users about downtime

Planned downtime

If your service cannot be available 24/7, inform users in advance and explain the reason.

Unplanned downtime

Use a status page or other real-time updates to keep users informed when unexpected issues occur.

Back to top