Digital infrastructure is only useful when people can rely on it.
At development.city, we design and operate our services with reliability in mind — while recognising that no digital system can honestly promise that nothing will ever go wrong.
Services can experience interruptions.
Third-party providers can have outages.
Networks can fail.
Software can develop unexpected problems.
The important thing is not pretending these things never happen.
It's building responsibly, detecting problems quickly, communicating clearly, and recovering as effectively as possible.
1. What Reliability Means to Us
Reliability is more than uptime.
A reliable digital service should also be:
Available when people need it
Consistent in how it behaves
Maintainable when something needs to change
Observable so problems can be identified
Recoverable when something goes wrong
Understandable when users need to know what is happening
That's why we consider reliability throughout the lifecycle of the infrastructure we operate.
2. Availability
We aim to keep our services available and operational for the people who depend on them.
The actual availability of an individual service can depend on:
The infrastructure involved
Third-party providers
Network connectivity
Planned maintenance
Service dependencies
The specific service agreement
Where a service includes a defined availability or uptime commitment, the applicable agreement takes precedence.
For services without a specific contractual availability commitment, we work to maintain a reliable service but cannot guarantee uninterrupted availability.
Reliable doesn't mean impossible to interrupt. It means designed to recover.
3. Monitoring
Where appropriate, our infrastructure includes monitoring and operational checks designed to help identify problems.
Depending on the service, this can include monitoring for:
Availability
Errors
Performance
Failed workflows
Integration problems
Authentication issues
Other operational signals
Monitoring helps us understand when something is wrong and, where possible, identify problems before they become widespread.
However, monitoring isn't magic.
Some problems can only become visible when a real user encounters them.
If something isn't working as expected, tell us.
Your report can be an important part of detecting a problem.
4. Maintenance
Digital infrastructure needs maintenance.
We may need to:
Apply updates
Improve performance
Change configurations
Replace components
Update integrations
Address security issues
Improve reliability
Introduce new functionality
Where maintenance is expected to materially affect a service, we'll aim to provide appropriate communication in advance when practical.
Some maintenance may need to happen quickly because delaying it could create a greater risk.
In those situations, protecting the service can sometimes be more important than waiting for the perfect maintenance window.
5. Third-Party Dependencies
Development City is an ecosystem.
That means some services may depend on external infrastructure, platforms, APIs, networks, payment providers, identity services, hosting providers, or other technologies.
If one of those services experiences an outage or significant change, it can affect parts of the development.city experience.
We can't control the availability of every external provider.
What we can do is:
Choose dependencies carefully.
Design integrations responsibly.
Monitor important workflows where practical.
Communicate when an external dependency is affecting your service.
Look for alternatives when a dependency becomes unsuitable.
6. What Happens During an Incident?
When we identify a significant service issue, the response will depend on the nature and impact of the incident.
This may include:
Identifying the affected service
Assessing the scope and impact
Investigating the cause
Applying a workaround or fix where possible
Monitoring the result
Communicating relevant information
Reviewing the incident afterwards where appropriate
Not every issue requires the same response.
A minor inconvenience and a widespread service disruption should not be treated as identical events.
We prioritise based on impact.
7. How to Report a Suspected Outage
If you believe a service is unavailable, first check whether the problem is limited to your device, connection, or account.
For example, you can try:
Refreshing the page
Checking another browser
Trying another connection
Confirming that other services are working
Checking whether other users are affected
If the problem continues, report it through the appropriate support channel.
Please include:
What service is affected?
What were you trying to do?
What happened?
When did it start?
Is anyone else affected?
Is the problem still happening?
If you have an error message or screenshot, include it where appropriate.
8. Don't Assume It's an Outage
Sometimes something that looks like an outage is actually:
An expired session
An account-access problem
A browser issue
A local network problem
An integration failure
A configuration issue
A third-party service problem
That's okay.
You don't need to diagnose it before contacting us.
Tell us what you're experiencing and we'll help determine where the problem is.
9. Service Status Communication
When appropriate, information about significant service interruptions or planned maintenance may be communicated through the relevant customer or support channels.
The exact communication method depends on the service and your relationship with us.
For services with formal status or incident communication procedures, those procedures take precedence.
We don't believe in sending notifications for every tiny technical event.
The goal is to provide useful information when people actually need it.
10. Reliability Is an Ongoing Process
Technology changes.
Infrastructure changes.
Threats change.
Providers change.
Customer expectations change.
That means reliability isn't something we can design once and forget.
We continuously look for opportunities to improve:
Resilience
Monitoring
Recovery
Documentation
Communication
Infrastructure design
Operational processes
When something goes wrong, we don't just want to get it working again.
Where appropriate, we also want to understand why it happened and whether we can reduce the chance of it happening again.
The Short Version
We design for reliability.
We monitor where appropriate.
We maintain the infrastructure.
We communicate when it matters.
We investigate problems when they occur.
We improve what we learn from them.
And one principle sits underneath all of it:
No system is perfect. Good infrastructure is prepared for imperfection.
Build better. Connect smarter. Scale sustainably.
#ForPeopleForPlanet