tj-scale 1.0.1 → 1.1.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: e05590797c077f70558b873341769561cab50e7407fe0933df596115ef475a10
-  data.tar.gz: c45d900f4d681d5be4b7e8752092f182c074a5cb5461177d71edde23c598018b
+  metadata.gz: 76a39f424b8bf07fbe1cd0812fa63833e403ce9c5983639e6f2644db2700b798
+  data.tar.gz: 78b517bd5a20e91d617dfbeddea44d085e1808442c24840034252b2140af286f
 SHA512:
-  metadata.gz: a7c59c9a515aa750175495fde1780eecff206cd1d051f7cd10e3a26b80059902af5f506033fa7c04b67c6ddcaf00adf48279ef3525852bcd0787d481d4cf78db
-  data.tar.gz: 2932a2bb1e4ad70029510117775afb334ed34233a03e6811cc65ad53573fdc0fa86832ed950675a1498bdbc98ba3296e470600c63fbde17c4f072ef2e59ce341
+  metadata.gz: 8995d5a220b907b77126f766c9f2c7b382cd445c8bd4f3da3b20509e072ef26e84092ee16462a0218693c211d44ad3f65769a10b421c639bdf0d02386a844a59
+  data.tar.gz: d534b2ceb99df75e41b4ee9b2495e00d5e0a105e2cdf9d3c579ef6202242d8ec953a1f71d8026a9f06359d6a03ba8c16dbc4123ac4dde9768dd34cb685d4a686

data/CHANGELOG.md

@@ -7,6 +7,38 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [1.1.0] (tj-scale) - 2026-06-12
+
+### Changed
+
+- **Monitor process is now auto-detected from Heroku's `DYNO` env var**: `web.1`
+  monitors web and `worker.1` monitors worker, so one app monitors both process
+  types with no Procfile env prefixes or extra config. `TJ_SCALE_MONITOR_PROCESS`
+  still pins a single process type when set explicitly; off-Heroku (no `DYNO`)
+  the default remains `worker`. Non-web/worker dynos (`release.*`, `run.*`,
+  `scheduler.*`) never start the metrics loop.
+- `target_process` (payload) follows the auto-detected process, so web samples
+  land on web scale rules and worker samples on worker rules automatically.
+
+### Added
+
+- **Custom process types**: any Heroku process type (e.g. `bulk-worker.1`) now
+  runs the monitor and reports job metrics under its own `target_process`, not
+  just `web`/`worker`. Platform dynos (`release`, `run`, `scheduler`, `console`,
+  `rake`) are excluded.
+- **Per-process Sidekiq queue filter**: `TJ_SCALE_SIDEKIQ_QUEUES_<PROCESS>`
+  (process name upcased, non-alphanumerics → `_`, e.g.
+  `TJ_SCALE_SIDEKIQ_QUEUES_BULK_WORKER=low`) overrides the global
+  `TJ_SCALE_SIDEKIQ_QUEUES` for that process, so a bulk fleet can scale on its
+  own queue's backlog while the worker fleet scales on the rest.
+
+## [1.0.2] (tj-scale) - 2026-06-12
+
+### Changed
+
+- README fully updated for the `tj-scale` name: install/build/publish instructions,
+  repository URLs (`Untechnickle/tj-scale-gem`), and generic example app names.
+
 ## [1.0.1] (tj-scale) - 2026-06-12
 
 ### Changed

data/README.md

@@ -1,10 +1,10 @@
-# TjScaleRuby
+# tj-scale
 
 [![Ruby Version](https://img.shields.io/badge/ruby-%3E%3D%203.0.0-red.svg)](https://www.ruby-lang.org/)
 [![Rails Version](https://img.shields.io/badge/rails-%3E%3D%206.1-red.svg)](https://rubyonrails.org/)
 [![License](https://img.shields.io/badge/license-MIT-green.svg)](LICENSE.txt)
 
-TjScaleRuby is a Ruby gem that automatically monitors your background job queues — **Delayed Job or Sidekiq** — and your web traffic, and sends metrics to a remote monitoring service for auto-scaling purposes. It integrates seamlessly with Rails applications and Heroku deployments.
+TJ Scale (`tj-scale`) is a Ruby gem that automatically monitors your background job queues — **Delayed Job or Sidekiq** — and your web traffic, and sends metrics to a remote monitoring service for auto-scaling purposes. It integrates seamlessly with Rails applications and Heroku deployments.
 
 ## Features
 
@@ -28,7 +28,7 @@ The control plane lives in its own project, **`tj-scale-dashboard`** (a sibling
 Add this line to your application's Gemfile:
 
 ```ruby
-gem "tj-scale-ruby", "~> 1.2"
+gem "tj-scale", "~> 1.0"
 ```
 
 And then execute:
@@ -40,7 +40,7 @@ $ bundle install
 Or install it yourself as:
 
 ```bash
-$ gem install tj-scale-ruby
+$ gem install tj-scale
 ```
 
 ### From Source
@@ -48,8 +48,8 @@ $ gem install tj-scale-ruby
 1. Clone the repository:
 
 ```bash
-git clone https://github.com/untechnickle/tj-scale-ruby.git
-cd tj-scale-ruby
+git clone https://github.com/Untechnickle/tj-scale-gem.git
+cd tj-scale-gem
 ```
 
 2. Install dependencies:
@@ -85,7 +85,7 @@ Build the gem, publish or reference it, add it to your Rails app, and set config
    cd /path/to/tj-scale
    git init   # if needed
    git add .
-   git commit -m "Release tj-scale-ruby"
+   git commit -m "Release tj-scale"
    ```
 
 2. **Install dependencies and verify quality**:
@@ -101,10 +101,10 @@ Build the gem, publish or reference it, add it to your Rails app, and set config
 4. **Build the package**:
 
    ```bash
-   gem build tj-scale-ruby.gemspec
+   gem build tj-scale.gemspec
    ```
 
-   This produces `tj-scale-ruby-<version>.gem` in the current directory.
+   This produces `tj-scale-<version>.gem` in the current directory.
 
 ### 3. Publish the gem (choose one)
 
@@ -114,13 +114,13 @@ Build the gem, publish or reference it, add it to your Rails app, and set config
 2. Push the file you built (version must match `VERSION`):
 
    ```bash
-   gem push tj-scale-ruby-1.0.0.gem
+   gem push tj-scale-1.0.1.gem
    ```
 
 **Private gem host**
 
 ```bash
-gem push tj-scale-ruby-1.0.0.gem --host https://your-gem-server.com
+gem push tj-scale-1.0.1.gem --host https://your-gem-server.com
 ```
 
 Configure Bundler in the app if your host needs authentication (see your provider’s docs).
@@ -130,9 +130,9 @@ Configure Bundler in the app if your host needs authentication (see your provide
 In the app’s `Gemfile`:
 
 ```ruby
-gem "tj-scale-ruby", git: "https://github.com/untechnickle/tj-scale-ruby.git", branch: "main"
+gem "tj-scale", git: "https://github.com/Untechnickle/tj-scale-gem.git", branch: "main"
 # or path for local development:
-# gem "tj-scale-ruby", path: "../tj-scale"
+# gem "tj-scale", path: "../tj-scale"
 ```
 
 Then `bundle install`.
@@ -142,7 +142,7 @@ Then `bundle install`.
 1. Open the app’s **`Gemfile`** and add (adjust version or source as above):
 
    ```ruby
-   gem "tj-scale-ruby", "~> 1.2"
+   gem "tj-scale", "~> 1.0"
    ```
 
 2. Run:
@@ -153,7 +153,7 @@ Then `bundle install`.
 
 3. **No extra `require`** is needed in `application.rb`: the gem registers a **Rails Railtie** and loads with Rails. Ensure your app already bundles its job backend — **`delayed_job_active_record`** or **`sidekiq`** (the gem auto-detects which one is loaded, or set `TJ_SCALE_JOB_BACKEND` explicitly).
 
-4. Deploy or run the server as usual. The monitoring thread starts only on **`web.1`** or **`worker.1`**, depending on `TJ_SCALE_MONITOR_PROCESS` (see below).
+4. Deploy or run the server as usual. The monitoring thread starts on **`web.1`** and **`worker.1`** automatically (process type auto-detected from Heroku's `DYNO`), so one app reports both web and worker metrics with no extra config. Set `TJ_SCALE_MONITOR_PROCESS` to pin a single process type (see below).
 
 ### 5. Configure environment variables
 
@@ -165,7 +165,7 @@ Configuration is **entirely via environment variables** (and Heroku **config var
 | `TJ_SCALE_API_URL` | Yes | Full URL of the Agent API ingest path: **`POST /api/v1/metrics`** or **`POST /api/v1/sys-logs`** (same handler). Example local: `http://127.0.0.1:5001/api/v1/metrics`. |
 | `TJ_SCALE_TARGET_APP` | No | Heroku app name to scale; defaults to **`HEROKU_APP_NAME`** if unset. |
 | `TJ_SCALE_TARGET_PROCESS` | No | `web` or `worker` to scale; defaults to `TJ_SCALE_MONITOR_PROCESS`. |
-| `TJ_SCALE_MONITOR_PROCESS` | No | `web` or `worker` — only that process’s **`.1`** dyno runs the reporter (default **`worker`**). |
+| `TJ_SCALE_MONITOR_PROCESS` | No | `web` or `worker` to pin the reporter to one process type. Default: auto-detected from `DYNO` (`web.1` reports web, `worker.1` reports worker); **`worker`** when `DYNO` is unset (non-Heroku). |
 | `TJ_SCALE_INTERVAL_SECONDS` | No | Seconds between posts (default **20**). |
 | `TJ_SCALE_JOB_BACKEND` | No | Queue backend for the **worker** reporter: `delayed_job`, `sidekiq`, or `auto` (default). `auto` uses Sidekiq when the `sidekiq` gem is loaded, otherwise Delayed Job. |
 | `TJ_SCALE_SIDEKIQ_QUEUES` | No | Sidekiq backend only: comma-separated queue names to count (empty = all queues). |
@@ -177,26 +177,26 @@ Configuration is **entirely via environment variables** (and Heroku **config var
 
 Heroku sets **`DYNO`** (for example `web.1`, `worker.1`) and typically **`HEROKU_APP_NAME`**; do not set **`DYNO`** manually in production.
 
-**Example: `revize-prod` (web) and `revize-prod-mirror` (workers)**
+**Example: `my-app-web` (web) and `my-app-workers` (workers)**
 
 Use the same token on both apps if one backend handles scaling.
 
 ```bash
-# revize-prod — reporter on web.1, scale web dynos
+# my-app-web — reporter on web.1, scale web dynos
 heroku config:set TJ_SCALE_API_TOKEN=your_token \
   TJ_SCALE_API_URL=https://your-control-plane.example.com/api/v1/metrics \
-  TJ_SCALE_TARGET_APP=revize-prod \
+  TJ_SCALE_TARGET_APP=my-app-web \
   TJ_SCALE_TARGET_PROCESS=web \
   TJ_SCALE_MONITOR_PROCESS=web \
-  -a revize-prod
+  -a my-app-web
 
-# revize-prod-mirror — reporter on worker.1, scale worker dynos
+# my-app-workers — reporter on worker.1, scale worker dynos
 heroku config:set TJ_SCALE_API_TOKEN=your_token \
   TJ_SCALE_API_URL=https://your-control-plane.example.com/api/v1/metrics \
-  TJ_SCALE_TARGET_APP=revize-prod-mirror \
+  TJ_SCALE_TARGET_APP=my-app-workers \
   TJ_SCALE_TARGET_PROCESS=worker \
   TJ_SCALE_MONITOR_PROCESS=worker \
-  -a revize-prod-mirror
+  -a my-app-workers
 ```
 
 On the **web** app, enable **`TJ_SCALE_ENABLE_QUEUE_TIME_MIDDLEWARE=1`** (and restart) so `queue_time_ms` is populated from Heroku’s router; the web dyno does not need a shared Delayed Job DB for that path.
@@ -214,7 +214,7 @@ The gem POSTs JSON with **`timestamp`**, **`heroku_app`**, **`target_process`**,
 
 ### 7. Verify
 
-- At least one **web** dyno on `revize-prod` and one **worker** dyno on `revize-prod-mirror` so **`web.1`** and **`worker.1`** exist.
+- At least one **web** dyno on `my-app-web` and one **worker** dyno on `my-app-workers` so **`web.1`** and **`worker.1`** exist.
 - Check **Rails logs** for `TjScaleRuby` lines (debug/warn/error).
 - Confirm your API receives periodic requests with the expected payload.
 
@@ -272,31 +272,31 @@ heroku config:set TJ_SCALE_API_TOKEN=your_api_token_here
 heroku config:set TJ_SCALE_API_URL=https://your-control-plane.example.com/api/v1/metrics
 ```
 
-The `DYNO` environment variable is automatically set by Heroku and is used to determine which dyno should run the monitoring loop (only `web.1` or `worker.1`, depending on `TJ_SCALE_MONITOR_PROCESS`).
+The `DYNO` environment variable is automatically set by Heroku and is used to determine which dynos run the monitoring loop: `web.1` and `worker.1` each report their own process type (override with `TJ_SCALE_MONITOR_PROCESS`).
 
-### Example: web on `revize-prod`, workers on `revize-prod-mirror`
+### Example: web on `my-app-web`, workers on `my-app-workers`
 
 Use two Heroku apps (or one app with both process types—same idea). Configure each app’s config vars so the **monitoring service** receives `heroku_app`, `target_process`, and `job_count` on each POST. Scaling bounds (min/max dynos) are set in the control plane's dashboard.
 
-**App `revize-prod` (web dynos)** — run the reporter on the first web dyno and scale `web` dynos:
+**App `my-app-web` (web dynos)** — run the reporter on the first web dyno and scale `web` dynos:
 
 ```bash
-heroku config:set TJ_SCALE_API_TOKEN=your_token -a revize-prod
-heroku config:set TJ_SCALE_MONITOR_PROCESS=web -a revize-prod
-heroku config:set TJ_SCALE_TARGET_APP=revize-prod -a revize-prod
-heroku config:set TJ_SCALE_TARGET_PROCESS=web -a revize-prod
-heroku config:set TJ_SCALE_API_URL=https://your-control-plane.example.com/api/v1/metrics -a revize-prod
-heroku config:set TJ_SCALE_ENABLE_QUEUE_TIME_MIDDLEWARE=1 -a revize-prod
+heroku config:set TJ_SCALE_API_TOKEN=your_token -a my-app-web
+heroku config:set TJ_SCALE_MONITOR_PROCESS=web -a my-app-web
+heroku config:set TJ_SCALE_TARGET_APP=my-app-web -a my-app-web
+heroku config:set TJ_SCALE_TARGET_PROCESS=web -a my-app-web
+heroku config:set TJ_SCALE_API_URL=https://your-control-plane.example.com/api/v1/metrics -a my-app-web
+heroku config:set TJ_SCALE_ENABLE_QUEUE_TIME_MIDDLEWARE=1 -a my-app-web
 ```
 
-**App `revize-prod-mirror` (worker dynos)** — run the reporter on `worker.1` and scale `worker` dynos:
+**App `my-app-workers` (worker dynos)** — run the reporter on `worker.1` and scale `worker` dynos:
 
 ```bash
-heroku config:set TJ_SCALE_API_TOKEN=your_token -a revize-prod-mirror
-heroku config:set TJ_SCALE_MONITOR_PROCESS=worker -a revize-prod-mirror
-heroku config:set TJ_SCALE_TARGET_APP=revize-prod-mirror -a revize-prod-mirror
-heroku config:set TJ_SCALE_TARGET_PROCESS=worker -a revize-prod-mirror
-heroku config:set TJ_SCALE_API_URL=https://your-control-plane.example.com/api/v1/metrics -a revize-prod-mirror
+heroku config:set TJ_SCALE_API_TOKEN=your_token -a my-app-workers
+heroku config:set TJ_SCALE_MONITOR_PROCESS=worker -a my-app-workers
+heroku config:set TJ_SCALE_TARGET_APP=my-app-workers -a my-app-workers
+heroku config:set TJ_SCALE_TARGET_PROCESS=worker -a my-app-workers
+heroku config:set TJ_SCALE_API_URL=https://your-control-plane.example.com/api/v1/metrics -a my-app-workers
 ```
 
 Ensure both apps have the `web` / `worker` process types in the `Procfile` as needed, deploy, and scale at least one dyno of each monitored type so `web.1` / `worker.1` exist.
@@ -307,7 +307,7 @@ Ensure both apps have the `web` / `worker` process types in the `Procfile` as ne
 
 ### Automatic Monitoring
 
-Once installed and configured, the gem starts monitoring on the first dyno of the configured process type (`web.1` or `worker.1`, see `TJ_SCALE_MONITOR_PROCESS`). The loop runs every `TJ_SCALE_INTERVAL_SECONDS` (default 20) and POSTs metrics to the configured API.
+Once installed and configured, the gem starts monitoring on the first dyno of each process type (`web.1` and `worker.1`; pin one with `TJ_SCALE_MONITOR_PROCESS`). The loop runs every `TJ_SCALE_INTERVAL_SECONDS` (default 20) and POSTs metrics to the configured API.
 
 ### Manual Usage
 
@@ -338,7 +338,7 @@ ENV['TJ_MAX_PRIORITY'] = '10'
 
 ## How It Works
 
-1. **Initialization**: When your Rails application starts, the `Railtie` checks if it's running on the first monitored dyno (`web.1` or `worker.1`, per `TJ_SCALE_MONITOR_PROCESS`)
+1. **Initialization**: When your Rails application starts, the `Railtie` checks if it's running on the first dyno of a monitored process type (`web.1` or `worker.1`, auto-detected from `DYNO`; `TJ_SCALE_MONITOR_PROCESS` pins one)
 2. **Background Thread**: If conditions are met, a background thread is started
 3. **Monitoring Loop**: Every N seconds (`TJ_SCALE_INTERVAL_SECONDS`), the thread POSTs a payload: on **worker** reporters it counts waiting jobs on the active backend; on **web** reporters it sends router queue time (middleware / env) plus request volume and average response time for the interval.
 4. **Job counting (worker reporters, Delayed Job backend)**: `pending_job_count` filters jobs based on:
@@ -388,7 +388,7 @@ For a full checklist (git, tests, version, integrate in the app, Heroku), see **
 3. Build the gem:
 
 ```bash
-gem build tj-scale-ruby.gemspec
+gem build tj-scale.gemspec
 ```
 
 This will create a `.gem` file in the current directory.
@@ -400,7 +400,7 @@ This will create a `.gem` file in the current directory.
 3. Configure your credentials:
 
 ```bash
-gem push --key your_api_key tj-scale-ruby-1.0.0.gem
+gem push --key your_api_key tj-scale-1.0.1.gem
 ```
 
 Or use the credentials file:
@@ -411,7 +411,7 @@ Or use the credentials file:
 # ---
 # :rubygems_api_key: your_api_key_here
 
-gem push tj-scale-ruby-1.0.0.gem
+gem push tj-scale-1.0.1.gem
 ```
 
 ### Publishing to a Private Gem Server
@@ -419,7 +419,7 @@ gem push tj-scale-ruby-1.0.0.gem
 If you're using a private gem server:
 
 ```bash
-gem push tj-scale-ruby-1.0.0.gem --host https://your-gem-server.com
+gem push tj-scale-1.0.1.gem --host https://your-gem-server.com
 ```
 
 ## Deployment
@@ -429,7 +429,7 @@ gem push tj-scale-ruby-1.0.0.gem --host https://your-gem-server.com
 1. Add the gem to your `Gemfile`:
 
 ```ruby
-gem "tj-scale-ruby", "~> 1.2"
+gem "tj-scale", "~> 1.0"
 ```
 
 2. Set the required environment variables:
@@ -469,7 +469,7 @@ The gem works with any Rails application. Just ensure:
 
 ## Contributing
 
-Bug reports and pull requests are welcome on GitHub at https://github.com/untechnickle/tj-scale-ruby.
+Bug reports and pull requests are welcome on GitHub at https://github.com/Untechnickle/tj-scale-gem.
 
 1. Fork the repository
 2. Create your feature branch (`git checkout -b feature/amazing-feature`)
@@ -491,7 +491,7 @@ See [CHANGELOG.md](CHANGELOG.md) for a list of changes and version history.
 
 ## Support
 
-For issues, questions, or contributions, please open an issue on the [GitHub repository](https://github.com/untechnickle/tj-scale-ruby/issues).
+For issues, questions, or contributions, please open an issue on the [GitHub repository](https://github.com/Untechnickle/tj-scale-gem/issues).
 
 ## Authors
 

data/lib/tj-scale.rb

@@ -11,8 +11,10 @@ require "tj_scale_ruby/models/tj_scale_ruby"
 # TJ Scale (the control plane) scales Heroku formation when ingested metrics cross rules
 # you configure there. This gem only **reports signals**; it never calls Heroku directly.
 #
-# **Where it runs:** A single background thread on **one** dyno — the first dyno of the
-# process you choose (`web.1` or `worker.1` via +TJ_SCALE_MONITOR_PROCESS+). Heroku sets +DYNO+.
+# **Where it runs:** A single background thread on the **first dyno of each process type**.
+# The process is auto-detected from Heroku's +DYNO+ (`web.1` monitors web, `worker.1` monitors
+# worker — so one app monitors both with no extra config). Set +TJ_SCALE_MONITOR_PROCESS+ to
+# pin a single process type instead; off-Heroku (no +DYNO+) the default is `worker`.
 #
 # **What it sends:** On each tick (+TJ_SCALE_INTERVAL_SECONDS+), it POSTs JSON to
 # +TJ_SCALE_API_URL+ (e.g. +/api/v1/metrics+ or +/api/v1/sys-logs+ — same handler on the
@@ -21,12 +23,12 @@ require "tj_scale_ruby/models/tj_scale_ruby"
 # includes +heroku_app+ and +target_process+; scaling limits (min/max dynos) live in the
 # control plane's settings, not in this gem.
 #
-# - **Worker monitor** (+TJ_SCALE_MONITOR_PROCESS=worker+): counts waiting jobs
+# - **Worker monitor** (on +worker.1+): counts waiting jobs
 #   (+job_count+, +queue_time_s+) on the configured queue backend — **Delayed Job** or **Sidekiq**,
 #   toggled with +TJ_SCALE_JOB_BACKEND+ (+delayed_job+ / +sidekiq+ / +auto+, the default, which
 #   prefers Sidekiq when loaded). Delayed Job needs +delayed_job_active_record+ and a shared DB;
 #   Sidekiq needs the +sidekiq+ gem and Redis (+TJ_SCALE_SIDEKIQ_QUEUES+ limits counted queues).
-# - **Web monitor** (+TJ_SCALE_MONITOR_PROCESS=web+): sends +queue_time_ms+ from Rack middleware
+# - **Web monitor** (on +web.1+): sends +queue_time_ms+ from Rack middleware
 #   (router queue via +X-Request-Start+) when +TJ_SCALE_ENABLE_QUEUE_TIME_MIDDLEWARE=1+, plus
 #   request volume and average +response_time_ms+ for the tick. Without middleware, set
 #   +TJ_SCALE_QUEUE_TIME_MS+ or the platform will not scale on queue time until data exists.
@@ -69,7 +71,8 @@ module TjScaleRuby
     end
   end
 
-  # True when this dyno should run the metrics loop (first of TJ_SCALE_MONITOR_PROCESS).
+  # True when this dyno should run the metrics loop: the first dyno (.1) of the
+  # monitored process type (auto-detected from DYNO, or TJ_SCALE_MONITOR_PROCESS).
   # Result is memoized; cleared by {.reset_configuration!}.
   def self.monitor_on_this_dyno?
     return @monitor_on_this_dyno if defined?(@monitor_on_this_dyno)

data/lib/tj_scale_ruby/configuration.rb

@@ -5,14 +5,21 @@ module TjScaleRuby
   class Configuration
     DEFAULT_INTERVAL_SECONDS = 20
     JOB_BACKENDS = %w[auto delayed_job sidekiq].freeze
+    # Any Heroku process type (web, worker, bulk-worker, …) is monitorable;
+    # platform dynos never run app monitoring.
+    PROCESS_NAME = /\A[a-z][a-z0-9_-]*\z/
+    NON_APP_PROCESSES = %w[release run scheduler console rake].freeze
 
     attr_reader :monitor_process, :interval_seconds,
       :min_priority, :max_priority, :job_backend, :sidekiq_queues
 
     def initialize(env = ENV)
-      @monitor_process = normalize_process(env["TJ_SCALE_MONITOR_PROCESS"]) || "worker"
+      @monitor_process = normalize_process(env["TJ_SCALE_MONITOR_PROCESS"]) ||
+        process_from_dyno(env["DYNO"]) || "worker"
       @job_backend = normalize_job_backend(env["TJ_SCALE_JOB_BACKEND"])
-      @sidekiq_queues = parse_list(env["TJ_SCALE_SIDEKIQ_QUEUES"])
+      @sidekiq_queues = parse_list(
+        env[sidekiq_queues_key(@monitor_process)] || env["TJ_SCALE_SIDEKIQ_QUEUES"]
+      )
       @interval_seconds = parse_positive_int(env["TJ_SCALE_INTERVAL_SECONDS"], DEFAULT_INTERVAL_SECONDS)
       @target_app = nonempty_string(env["TJ_SCALE_TARGET_APP"])
       @heroku_app_name = nonempty_string(env["HEROKU_APP_NAME"])
@@ -33,11 +40,24 @@ module TjScaleRuby
 
     private
 
+    # Auto-detect from Heroku's DYNO (web.1 → web, worker.1 → worker) so one app
+    # can monitor both process types without per-process env. Nil off-Heroku and
+    # for non-web/worker dynos (release.1, run.x, scheduler.x).
+    def process_from_dyno(dyno)
+      normalize_process(dyno.to_s.split(".").first)
+    end
+
     def normalize_process(value)
       p = value.to_s.strip.downcase
-      return nil if p.empty?
+      return nil if p.empty? || NON_APP_PROCESSES.include?(p)
+
+      PROCESS_NAME.match?(p) ? p : nil
+    end
 
-      %w[web worker].include?(p) ? p : nil
+    # Per-process Sidekiq queue filter, e.g. TJ_SCALE_SIDEKIQ_QUEUES_BULK_WORKER=low
+    # for a +bulk-worker+ process; falls back to TJ_SCALE_SIDEKIQ_QUEUES.
+    def sidekiq_queues_key(process)
+      "TJ_SCALE_SIDEKIQ_QUEUES_#{process.to_s.upcase.gsub(/[^A-Z0-9]/, '_')}"
     end
 
     # "delayed_job" | "sidekiq" | "auto" (default; detects from loaded gems).

data/lib/tj_scale_ruby/version.rb

@@ -2,5 +2,5 @@
 
 # Version module for TjScaleRuby gem
 module TjScaleRuby
-  VERSION = "1.0.1"
+  VERSION = "1.1.0"
 end

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: tj-scale
 version: !ruby/object:Gem::Version
-  version: 1.0.1
+  version: 1.1.0
 platform: ruby
 authors:
 - Tanuj