Meteor 1.4 Settings API: alert thresholds frozen at startup after moving off --settings files

Answer

Yes—Meteor.settings immutability after startup is intended, not a bug. There is no supported runtime reload API for it, and environment variables share the same startup-only lifecycle. For thresholds that must change without a restart, the recommended Meteor-native pattern is a MongoDB-backed configuration collection. Current releases continue to treat settings as a startup snapshot; the 1.4 semantics have not been superseded by a new reload mechanism.

What is confirmed vs. what to verify

Confirmed behavior: Meteor.settings is populated during server boot and is not designed to be reassigned at runtime. Environment variables are read once at process start.

Items to verify in your deployment: whether your current Meteor version has introduced any new configuration hooks, and whether your hosting platform injects settings through a mechanism other than the standard --settings file.

Steps for dynamic alert thresholds

1. Create a server-side collection for configuration, for example Config = new Mongo.Collection('app_config').
2. Store threshold documents such as { _id: 'errorRateThreshold', value: 50 }.
3. Read the threshold inside your alert evaluation logic with Config.findOne('errorRateThreshold').value.
4. Optionally cache the value in a server-side variable and refresh it on a timer or via an admin method to reduce database reads.

Safety note

Do not rely on mutating Meteor.settings in memory. It may appear to work on a single local instance, but it is unsupported, does not persist, and will not propagate across a cluster.

One diagnostic question

Do you already have an external configuration service available, or is MongoDB your only shared state store? If MongoDB is the only shared store, the config-collection pattern is the simplest path; if you already use an external service, that may be preferable to avoid adding a database dependency to your alerting path.