Remote config for signals
Letting the dashboard control what the SDKs collect — turning signals on and off and tuning sample rates from the server, no redeploy required.
A quick but powerful one: remote config for the auth and filesystem signals.
The problem with local config
Up to now, what an SDK collects is decided in the app's own config. Want to turn off auth monitoring, or sample traces at 10%? Edit config, redeploy. That's fine until you're mid-incident and need to crank sampling up to 100% right now to catch a rare bug — and a deploy is the last thing you want to do at 2am.
Config that comes from the server
So signals now learn their settings from the dashboard. The SDK fetches config — which signals are enabled, each one's sample rate — stamped with a config_version. Flip auth monitoring on, dial trace sampling from 10% to 100%, and the change reaches the SDK on its next config refresh. No redeploy.
It also closes the loop on the opt-in watchers: sensitive signals stay off by default, and you enable them from the dashboard when you decide to — a deliberate, auditable switch rather than a code change buried in a PR.
The shape
The server owns the truth: per-project, per-signal enable flags and sample rates, plus a version stamp so the SDK knows when to apply changes. The SDK side is intentionally dumb — fetch, cache, obey. All the policy lives where you can actually see and change it.
This is the kind of feature that feels minor on a calm day and indispensable during an incident. Next: the user-facing payoff — a whole Security section.