How dependencies shape business application availability
Cloud application outages can stem from failures in supporting services and infrastructure. A failed sign-in may result from an authentication service outage, an inaccessible website from a DNS or network issue, and an unconfirmed order from a database or payment processing failure. Mapping these dependencies in advance and deciding how the application should respond when they become unavailable can prevent individual service failures from disrupting essential business operations.
Understanding hard and soft dependencies
In cloud application architecture, dependencies can be classified as hard or soft, depending on how essential they are to an application’s core functionality. A hard dependency is a service or component the application cannot function without. A soft dependency is one that can become unavailable without stopping the application’s essential functions, although some features may be limited or temporarily unavailable.
Applications should be designed to keep their essential functions running even when a supporting service becomes unavailable. For example, an online store should still allow customers to place orders if its product recommendation service goes down. Customers may lose personalized suggestions, but they should still be able to browse products and complete purchases.
Four dependencies that affect cloud application availability
There are four critical dependencies that require careful planning and management: identity providers, DNS, third-party APIs, and background processing systems.
Identity providers
Single sign-on makes it easier for employees to access multiple applications with one set of login credentials. However, if the identity provider responsible for verifying those credentials becomes unavailable, employees may lose access to applications that are otherwise working normally. Employees who are already signed in may also lose access when their login sessions expire.
To reduce disruption, set session durations carefully so employees are not all forced to sign in again during a brief service outage. Balance this with security requirements. Also, maintain a small number of emergency administrator accounts that can be accessed independently of the main sign-in service. Protect these accounts with strong multifactor authentication and test them regularly to ensure they work when needed.
DNS
DNS (Domain Name System) helps users and applications find websites and online services by translating domain names into the addresses computers use to connect. If DNS stops working, users may be unable to reach websites even when the servers hosting them are still running. Applications may also lose access to other services they depend on.
To reduce this risk, consider using a backup DNS provider for important domains so another provider can take over if the primary one fails. Set DNS record update times (known as time-to-live or TTL values) to allow changes to take effect within an appropriate timeframe. Secure your domain registrar account, keep track of renewal dates, and make sure designated team members know how to update DNS records during an emergency and where to access the required credentials.
Third-party APIs
Payment processors, shipping services, messaging platforms, and mapping tools often rely on external services to provide essential features. If one of these services responds slowly or stops working, the application may struggle to complete tasks that depend on it. A slow response can be particularly disruptive because the application may continue waiting, tying up resources that other users need.
To limit the impact, configure time limits so the application does not wait indefinitely for an external service. Limit the number of automatic retries and use a circuit breaker, which temporarily stops requests to a service that is repeatedly failing. Where possible, provide an alternative result rather than leaving users waiting.
For example, a travel booking platform could display previously retrieved hotel availability information while a hotel provider’s API is temporarily unavailable, rather than leaving users waiting for the page to load. Keep these alternatives simple and avoid complicated workarounds that introduce additional dependencies or potential points of failure.
Background processing
Queues and background jobs let applications handle tasks without making users wait. For example, an employee management system can save a leave request immediately while processing approval notifications or updating payroll records in the background. However, if a service needed to complete these tasks becomes unavailable, unfinished work can pile up. Repeated retries can make the backlog worse and overwhelm the service when it recovers.
To limit disruption, set limits on automatic retries and the number of tasks waiting in a queue. Use a dead letter queue (DLQ), a separate holding area for tasks that repeatedly fail, so they can be investigated and processed later without blocking other work. Keep essential user-facing functions running independently of background tasks, and identify which jobs must be completed promptly and which can safely wait.
Map the chain and rehearse the failures
For each critical application, identify the services it relies on, then determine which services are essential for the application to function and which can become unavailable without stopping its core features. Document what users would experience if each service failed and test whether the application can continue operating under those conditions.
A common mistake is failing to identify which application functions are essential to business operations or assuming they will continue working when a supporting service fails without testing them. Businesses that rely on Software-as-a-Service (SaaS) products should also ask vendors about their service dependencies, outage procedures, and availability commitments, and include this information in vendor assessments.
If you’re unsure how exposed your business applications are to a single failing service, we can help. Our team can map your critical dependencies, identify the weak points, , and help you plan how to keep essential application features available during an outage. Contact us to start the review.
When a cloud application becomes unavailable, the cause may lie in a service it depends on rather than in the application itself. Identity providers, DNS, third-party APIs, and background processing all play a role in delivering a working service to users. Identifying which dependencies are essential to business operations helps organizations prepare for service disruptions and keep critical application functions running.
A business application can become unavailable even when its core systems are working. A failed identity provider, DNS resolution issue, unresponsive payment API, or backed-up job queue can prevent users from completing essential tasks. These services are dependencies that applications rely on to function. Understanding which dependencies are critical to business operations is essential to maintaining availability when individual services fail.
Every business has at least one person who knows why things are configured the way they are. Until that knowledge is written down, it belongs to the individual rather than the company. Keeping a simple log of technology decisions turns individual knowledge into a shared reference material and makes leadership transitions far smoother.
Offboarding checklists cover accounts, devices, and badges but rarely capture the reasoning behind IT decisions. An IT decision log fills that gap by recording key decisions, why they were made, and which systems they affect. This helps businesses retain critical knowledge when employees leave.
When a long-tenured employee leaves, the most valuable knowledge they take with them is rarely a list of passwords. Rather, it’s the reasoning behind IT decisions: why a firewall rule exists, why backups run at two in the morning, or why one vendor was chosen over another. Access can be transferred quickly, but that knowledge is harder to replace. An IT decision log preserves institutional knowledge by recording what was decided, why, and what depends on it.
For small and medium-sized businesses (SMBs), knowing who makes key decisions during a cyberattack is essential. A cybersecurity tabletop exercise helps teams identify responsibilities, test response procedures, and clarify escalation paths before an actual breach occurs. Through guided discussions rather than live system testing, businesses can improve their incident readiness without disrupting daily operations.
An incident response plan that has never been rehearsed is an assumption, not a capability. Tabletop exercises let a team test its plan on paper: a facilitator presents a scenario, and participants work through decisions, handoffs, and communication as the situation develops. The format is low-cost, low-risk, and well suited to small and medium-sized businesses (SMBs) that cannot pause operations to run a drill.
Most small and midsize businesses (SMBs) keep an incident response plan on a shared drive and never test it with the people who would have to use it. A tabletop exercise closes that gap. It is a facilitated walkthrough of a realistic incident in which participants talk through what they would do, who decides, and who gets called. Because no live systems are touched, it takes a couple of hours and barely interrupts normal work.
A 2026 study found that 73 percent of Americans expect significant disruption within 24 hours of a major cloud outage, and more than half would feel the impact within four hours. For businesses whose operations depend on SaaS tools for communication, project management, finance, or customer service, an unplanned outage without a response plan means every affected employee is improvising. A runbook that staff can find and follow quickly converts a chaotic situation into a managed one.