{"id":1225,"date":"2026-09-03T10:57:10","date_gmt":"2026-09-03T09:57:10","guid":{"rendered":"https:\/\/ruby-doc.org\/learn\/?p=1225"},"modified":"2026-09-03T14:58:08","modified_gmt":"2026-09-03T13:58:08","slug":"the-rails-app-was-running-but-it-wasnt-working","status":"publish","type":"post","link":"https:\/\/ruby-doc.org\/learn\/the-rails-app-was-running-but-it-wasnt-working\/","title":{"rendered":"The Rails App Was Running, But It Wasn\u2019t Working"},"content":{"rendered":"\n

Written by James Britt<\/a><\/strong>
Technically reviewed by Jim Freeze<\/a> \u00b7 Reviewed 3 September 2026<\/p>\n\n\n\n

A Rails app can look as if it is running smoothly while failing to deliver something customers depend upon. The hosting dashboard is green, each basic uptime check passes and yet some critical tasks simply don’t get completed.<\/p>\n\n\n\n

The company in this example is fictional, but the failure pattern is a familiar one in production Rails applications.<\/p>\n\n\n\n

A Silent Failure After Deployment<\/h2>\n\n\n\n

On Tuesday at 10:14, a small subscription service deployed a routine change. The web process started normally. Customers could log in, see their account information and even edit their profiles. The hosting dashboard indicated that everything was green.<\/p>\n\n\n\n

At 10:22, a broken Redis connection left the Sidekiq worker processes active but unable to complete their assigned work. Password-reset emails, receipts and webhook deliveries began piling up silently, invisible to anyone checking the website. At 10:47, a customer contacted support because a reset email had not arrived. That complaint was the first useful signal that something was wrong.<\/p>\n\n\n\n

The developer involved now had to stop what they were doing, review logs, check the deployment time, measure queue delays and help support determine how long customers had experienced the problem. While repairing the issue might require only five minutes, finding what went wrong, identifying what it impacted and notifying customers took much longer.<\/p>\n\n\n\n

That is when effective Ruby on Rails monitoring needs to begin. “Can visitors access the homepage?” is only one of several questions we need to answer.<\/p>\n\n\n\n

Define What Healthy Looks Like<\/h2>\n\n\n\n

For most Rails apps, I’d like to see monitoring answer the following three questions:<\/p>\n\n\n\n

    \n
  1. Is the Rails process running?<\/li>\n\n\n\n
  2. Are application dependencies available when requested?<\/li>\n\n\n\n
  3. Are asynchronous jobs still processing?<\/li>\n<\/ol>\n\n\n\n

    We do not need to create a single endpoint to handle these three questions. A fast low-cost liveness check can run regularly. More expensive deeper checks can run less frequently and evaluate a handful of key dependent resources required by the application for its primary purpose.<\/p>\n\n\n\n

    Keeping these checks separate makes an alert easier to interpret. If Rails responds but the dependency check fails, I am probably dealing with an application dependency rather than a non-responsive web process.<\/p>\n\n\n\n

    Start With Rails’ Built-In \/up Endpoint<\/h2>\n\n\n\n

    Rails includes a built-in health endpoint at \/up. It returns a successful response when the application has booted without raising an exception and an error response otherwise. The route normally looks like this:<\/p>\n\n\n\n

    get \"up\" => \"rails\/health#show\", as: :rails_health_check<\/code><\/pre>\n\n\n\n
    According to the Rails API documentation<\/a>, \/up is defined as a default health check that reports whether the application successfully booted.<\/p>\n\n\n\n
    Keep it. It is a useful liveness signal for a load balancer or an external monitor. Just remember what it does not establish: a successful response from \/up does not prove that the database accepts queries, Redis is accessible or background jobs are being processed.<\/p>\n\n\n\n
    Create Another Route to Monitor Dependencies<\/h2>\n\n\n\n
    To test the dependencies used by the subscription service, add another route:<\/p>\n\n\n\n
    get \"health\", to: \"health#show\"<\/code><\/pre>\n\n\n\n
    Your controller can test both your database and Redis without revealing internal implementation details:<\/p>\n\n\n\n
    class HealthController < ActionController::API\n  def show\n    checks = {\n      application: \"ok\",\n      database: database_status,\n      redis: redis_status\n    }\n\n    healthy = checks.values.all? { |value| value == \"ok\" }\n\n    render(\n      json: {\n        status: healthy ? \"ok\" : \"degraded\",\n        checks: checks\n      },\n      status: healthy ? :ok : :service_unavailable\n    )\n  end\n\n  private\n\n  def database_status\n    ActiveRecord::Base.connection.execute(\"SELECT 1\")\n    \"ok\"\n  rescue StandardError\n    \"failed\"\n  end\n\n  def redis_status\n    Sidekiq.redis { |connection| connection.ping }\n    \"ok\"\n  rescue StandardError\n    \"failed\"\n  end\nend<\/code><\/pre>\n\n\n\n
    A typical JSON response should contain minimal data:<\/p>\n\n\n\n
    {\n  \"status\": \"ok\",\n  \"checks\": {\n    \"application\": \"ok\",\n    \"database\": \"ok\",\n    \"redis\": \"ok\"\n  }\n}<\/code><\/pre>\n\n\n\n
    If Redis isn’t reachable, the health check returns HTTP 503 Service Unavailable along with a generic “failed” state. An external monitor receives a valid signal but users don’t receive hostnames, credentials or raw exception messages.<\/p>\n\n\n\n
    Remove the Redis check if the application does not<\/a><\/em> use Sidekiq. If another service is essential to the application’s core job, test that instead. Developers wishing to modify the ruby code shown here can refer to these real-world examples of Ruby code<\/a>.<\/p>\n\n\n\n
    Avoid Making \/health Overly Complex<\/h2>\n\n\n\n
    A health endpoint can easily become a laundry list of all of your systems and services. I would recommend against that.<\/p>\n\n\n\n
    A single call to your app can contact multiple services. There are many potential points of failure. And, you’re adding unnecessary traffic during a period when one of those systems may be experiencing performance degradation.<\/p>\n\n\n\n
    It’s usually best to have two separate levels of checks:<\/p>\n\n\n\n