---
title: "Seven Ways to Fortify Your Application"
description: "Applications can fail when a single upstream service goes down, prompting tools that shed load, fail gracefully, and protect struggling dependencies. The discussion frames this as application resilience for everyday failures, distinct from request-level retries, rollback strategies, and catastrophic disaster recovery. It presents maintenance mode as an easily toggled hard stop with a clear message and status-page link, read-only mode as a way to preserve access when modifications fail, and feature flags as controls for global or meaningful groups. Implementation examples include environment variables, relational databases, Redis, in-memory caches, and an S3-based check, with state stored primarily in Postgres and Redis at Heroku. The closing guidance says maintenance mode should be easy to toggle, while read-only mode can preserve user confidence and access to information."
---

# Seven Ways to Fortify Your Application

[Heroku](https://yomu.fyi/company/heroku) · Amy Unger · Mar 20, 2019

**Type:** Explainer

## Summary

Applications can fail when a single upstream service goes down, prompting tools that shed load, fail gracefully, and protect struggling dependencies. The discussion frames this as application resilience for everyday failures, distinct from request-level retries, rollback strategies, and catastrophic disaster recovery. It presents maintenance mode as an easily toggled hard stop with a clear message and status-page link, read-only mode as a way to preserve access when modifications fail, and feature flags as controls for global or meaningful groups. Implementation examples include environment variables, relational databases, Redis, in-memory caches, and an S3-based check, with state stored primarily in Postgres and Redis at Heroku. The closing guidance says maintenance mode should be easy to toggle, while read-only mode can preserve user confidence and access to information.

## Context

Applications may become unavailable or unsafe to operate when upstream services fail, data modifications stop working, or dependent services struggle. The material focuses on everyday operational failures and explicitly excludes request-level retries, multi-step rollback strategies, and catastrophic disaster recovery.

## Approach / What changed

The material presents operational controls for changing application behavior during failures: easily toggled maintenance mode, read-only mode, and feature flags at user, global, or group scope. It discusses implementing these controls with environment variables and state backed by relational databases, Redis, in-memory caches, or an S3-based check.

## Takeaways

- Maintenance mode should provide a clear, consistent message with a status-page link and be switchable through one simple control, such as an environment variable.
- Read-only mode can preserve access to information when an application cannot modify data, helping users retrieve data and understand whether recent changes succeeded.
- Feature flags can control degraded behavior globally or for meaningful groups, and their state should remain accessible even when the failing component is unavailable.

**Tags:** [Incident Response](https://yomu.fyi/topic/incident-response), [Reliability](https://yomu.fyi/topic/reliability), [Ruby](https://yomu.fyi/topic/ruby)

- Source: [Heroku](https://www.heroku.com/blog/seven-ways-to-fortify-your-application)
- Source URL: https://www.heroku.com/blog/seven-ways-to-fortify-your-application
- Ingested by Yomu: 2026-09-09T14:27:13.103Z

[Read original post](https://www.heroku.com/blog/seven-ways-to-fortify-your-application)