InfluxDB 1.x auth-enabled=true: application writes succeed but continuous queries stop populating retention policy

Short answer

Continuous queries in InfluxDB 1.x run as an internal server process, not under the identity of the user who created them. Enabling auth-enabled=true does not, by itself, break CQ writes, and dropping or revoking the creating user does not stop a CQ. When a downsampled retention policy stops populating right after auth is enabled, the usual cause is upstream: the application's writes are now failing with 401/403, so the CQ has no new source data to aggregate. An empty target RP almost always means empty input, not a failed CQ.

Likely explanation vs. confirmed facts

Confirmed behavior:

• CQs execute inside the server on a schedule derived from their EVERY/FOR clauses. They do not carry the creator's credentials, so user management changes don't disable them.
• SHOW CONTINUOUS QUERIES only lists definitions. It reports no last-run timestamp and no errors.
• CQ execution and any failures are written to the InfluxDB server log (journald or /var/log/influxdb, depending on how you run it), typically with "continuous query" in the message.

Likely explanation for your case: your application "writes succeed" only in the sense that no exception is thrown. Many InfluxDB clients don't raise on non-2xx responses, so a 401 (no credentials) or 403 (missing WRITE grant) looks like success. A second possibility is an RP mismatch introduced while re-creating users/databases: writes land in autogen while the CQ selects from a named RP (or the reverse). Fully qualified measurement names in the CQ (db.rp.measurement) make this explicit.

Steps for this case

1. Verify a write actually succeeds. Send one point with credentials and check the status code — you want HTTP 204:

   curl -i -u appuser:secret -XPOST \
     'http://localhost:8086/write?db=mydb' \
     --data-binary 'cq_test,tag=a value=1'

   A 401/403 here explains the empty downsampled RP: fix the client's credentials or GRANT WRITE ON mydb TO appuser.
2. Confirm source data exists inside the CQ's window:

   SELECT count(*) FROM "mydb"."autogen"."raw_measurement"
   WHERE time > now() - 1h  -- match the CQ's FOR interval

3. Run the CQ's SELECT ... INTO manually as an authenticated admin. If it returns and writes rows, the CQ logic is fine and the problem is input data.
4. Check the server log around scheduled run times:

   journalctl -u influxdb | grep -i 'continuous query' | tail -20

5. Confirm the target RP directly and compare timestamps against the CQ interval:

   SELECT * FROM "mydb"."downsampled_rp"."agg_measurement"
   ORDER BY time DESC LIMIT 5

Caveats

Exact log wording and CQ scheduling details vary across 1.x minor versions, so verify against your deployed version. Also note that dropping and re-creating a CQ resets its internal execution watermark, which can cause reprocessing or gaps — avoid recreating CQs as a "fix" until you've confirmed where the data flow actually breaks.

One diagnostic detail that would change this recommendation: the HTTP status code your application receives on writes. If it is genuinely 204 and source points exist in the correct RP, then the CQ itself or its RP qualification needs a closer look.