Skip to content
ProxRad Docs

FUP Not Resetting

The daily FUP counter (daily_quota_used) should drop to zero at the configured reset time every day, and subscribers in FUP tier 1/2/3 should get their full plan speed back. When it doesn’t reset, customers are throttled all day and you start getting calls. Four common causes, in order of likelihood.

Symptoms

Section titled “Symptoms”
  • It’s 09:00 the next morning and daily_quota_used on the subscribers page still shows yesterday’s number
  • Customer says “my internet is still slow after midnight”
  • FUP tier badge (Tier 1 / 2 / 3) doesn’t clear at the configured reset time
  • API logs show no DailyQuotaResetService lines around midnight
  • last_daily_reset column shows a date from days ago

Diagnostic flow

Section titled “Diagnostic flow”

  1. Confirm the service is running. It logs every cycle and prints loud lines when the reset fires.

    Terminal window
    docker logs proxpanel-api 2>&1 | grep -E "DailyQuotaResetService" | tail -30

    You should see DailyQuotaResetService started at the last API restart, then a DailyQuotaResetService: Running scheduled reset at HH:MM line at the configured time.

  2. Confirm the reset time and timezone match what you expect.

    Terminal window
    docker exec proxpanel-db psql -U proxpanel -d proxpanel -c \
      "SELECT key, value FROM system_preferences WHERE key IN ('daily_quota_reset_time', 'system_timezone');"

    Default is 00:05 Asia/Beirut. If system_timezone is empty or invalid, the service runs in UTC — your “midnight” is 02:00 / 03:00 local depending on DST.

  3. Check whether the API container was up at the configured time. If you restarted at 23:58 and the service started at 00:00 cleanly, the reset still ran. If you restarted at 00:04 and the service was down at the configured 00:05, it missed.

    Terminal window
    docker inspect proxpanel-api --format '{{.State.StartedAt}}'

  4. Look at one subscriber’s reset history.

    Terminal window
    docker exec proxpanel-db psql -U proxpanel -d proxpanel -c \
      "SELECT username, daily_quota_used, daily_download_used, fup_level, last_daily_reset \
       FROM subscribers WHERE username = 'USERNAME';"

Cause 1 — Wrong timezone (tzdata missing)

Section titled “Cause 1 — Wrong timezone (tzdata missing)”

The service calls time.LoadLocation("Asia/Beirut") (or whatever system_timezone is). Inside the Docker container, LoadLocation needs the tzdata package. If tzdata isn’t installed, LoadLocation returns an error and the service silently falls back to UTC.

This is the most common reset bug. It was fixed for fresh installs in v1.0.95 — but older installs that upgraded never got tzdata added to the container.

Diagnostic:

Terminal window
# Is tzdata installed?
docker exec proxpanel-api dpkg -l | grep tzdata


# Or: does the file exist?
docker exec proxpanel-api ls -la /usr/share/zoneinfo/Asia/Beirut

If you get “package not found” or “No such file”, tzdata is missing.

Fix:

  1. Install it in the running container so you don’t have to wait for a redeploy:

    Terminal window
    docker exec proxpanel-api apt-get update
    docker exec proxpanel-api apt-get install -y tzdata
    docker restart proxpanel-api

  2. After restart, watch the log — the service prints the timezone it loaded:

    Terminal window
    docker logs proxpanel-api 2>&1 | grep -E "Timezone|DailyQuotaResetService"

  3. Make it stick. On the next update, tzdata is included in the build (per the v1.0.95 fix in docker-compose.prod.yml). Verify with the same dpkg -l after an update lands.

Cause 2 — Reset time misconfigured

Section titled “Cause 2 — Reset time misconfigured”

daily_quota_reset_time was changed but system_timezone was not, or vice versa. Or someone typed 0:05 instead of 00:05 and the service can’t parse it.

Diagnostic:

Terminal window
docker exec proxpanel-db psql -U proxpanel -d proxpanel -c \
  "SELECT key, value FROM system_preferences \
   WHERE key IN ('daily_quota_reset_time', 'system_timezone');"

Expected:

 daily_quota_reset_time | 00:05
 system_timezone        | Asia/Beirut

Bad shapes: empty value, missing leading zero, a timezone string like GMT+2 (not in tzdata).

Fix:

In the UI: Settings → RADIUS → Daily Quota Reset Time, and Settings → General → Timezone. Save. The service re-reads system_preferences every cycle, so the change takes effect on the next reset window without a restart.

Or set directly:

Terminal window
docker exec proxpanel-db psql -U proxpanel -d proxpanel -c \
  "UPDATE system_preferences SET value='00:05' WHERE key='daily_quota_reset_time'; \
   UPDATE system_preferences SET value='Asia/Beirut' WHERE key='system_timezone';"

Cause 3 — API container restarted across the reset time

Section titled “Cause 3 — API container restarted across the reset time”

The service checks the configured time once per cycle. If the API container was down between 00:04 and 00:06 with a reset configured for 00:05, that day’s reset is lost — the service does not catch up on the next start.

Diagnostic:

Terminal window
# When did the API container last start?
docker inspect proxpanel-api --format '{{.State.StartedAt}}'


# Was there a restart loop?
docker inspect proxpanel-api --format '{{.RestartCount}}'

If RestartCount is non-zero recently, the container has been bouncing — check docker logs proxpanel-api --since=1h for crash reasons (commonly: license server unreachable past grace, or a Postgres connectivity blip).

Fix:

  1. Stabilise the container first. Resolve whatever caused the restart loop (see License Errors if it’s licence-related).
  2. Push a manual reset for today so customers stop calling: 
    UPDATE subscribers
    SET daily_quota_used = 0,
        daily_download_used = 0,
        daily_upload_used = 0,
        fup_level = 0,
        last_daily_reset = NOW()
    WHERE deleted_at IS NULL;
    Run inside docker exec proxpanel-db psql -U proxpanel -d proxpanel. Then push the correct rate to anyone still online via bulk Reset FUP in the UI.
  3. Shift the reset time to a window when restarts are less likely (e.g. 03:30 if updates land at 03:23 nightly).

Cause 4 — Reset ran but didn’t persist (last_daily_reset stale)

Section titled “Cause 4 — Reset ran but didn’t persist (last_daily_reset stale)”

last_daily_reset exists on every subscriber. The service writes it on every successful reset. If you see the log line DailyQuotaResetService: Reset daily quotas for N subscribers but a sample subscriber’s last_daily_reset is still days old, the UPDATE didn’t commit — usually a Postgres connection issue or a deleted_at filter mismatch.

Diagnostic:

Terminal window
# How many subscribers have a fresh last_daily_reset?
docker exec proxpanel-db psql -U proxpanel -d proxpanel -c \
  "SELECT date_trunc('day', last_daily_reset) AS reset_day, COUNT(*) \
   FROM subscribers WHERE deleted_at IS NULL \
   GROUP BY 1 ORDER BY 1 DESC LIMIT 5;"

You should see today (or yesterday) at the top with a count matching your total subscribers. If the top entry is days old or there’s a big gap, the UPDATE didn’t reach all rows.

Fix:

If you see the log line but the column is stale, file a bug at info@proxrad.com with the log timestamp and the query output. While you wait, the manual UPDATE subscribers SET daily_quota_used = 0, last_daily_reset = NOW() ... from Cause 3 works as a one-off.

Cause 5 — Subscriber excluded by service flag

Section titled “Cause 5 — Subscriber excluded by service flag”

The reset is system-wide, but if a service has time_based_speed_enabled = true and the quota-discount window straddles midnight, the FUP tier can re-apply within seconds of the reset. The counter resets, then a single 30-second QuotaSync cycle pushes the user back into Tier 1 because they’re still over the daily quota from before the cycle baseline updated.

Diagnostic:

Terminal window
docker logs proxpanel-api 2>&1 | grep -E "FUP|TimeSpeed" | grep "USERNAME" | tail -20

If you see the FUP tier re-applied within a minute of the reset, this is what’s happening.

Fix:

This is by design when the customer is still over the daily quota for “yesterday” and the QuotaSync baseline carries that delta. Wait one full QuotaSync cycle (30 s) after the reset; the next cycle’s delta starts from zero and the tier clears. If the reset is at 00:05 and customers complain at 00:06, that’s normal — by 00:10 it’s resolved.

Still stuck?

Section titled “Still stuck?”

Send:

Terminal window
# Reset config
docker exec proxpanel-db psql -U proxpanel -d proxpanel -c \
  "SELECT * FROM system_preferences WHERE key IN ('daily_quota_reset_time', 'system_timezone');"


# Last 24h of relevant API log
docker logs --since=24h proxpanel-api 2>&1 | grep -E "DailyQuotaResetService|Timezone|tzdata" > /tmp/reset.log


# tzdata status
docker exec proxpanel-api dpkg -l | grep tzdata


# Container restart history
docker inspect proxpanel-api --format '{{.State.StartedAt}} restarts={{.RestartCount}}'


# Distribution of last_daily_reset
docker exec proxpanel-db psql -U proxpanel -d proxpanel -c \
  "SELECT date_trunc('day', last_daily_reset) AS d, COUNT(*) FROM subscribers \
   WHERE deleted_at IS NULL GROUP BY 1 ORDER BY 1 DESC LIMIT 10;"

Send to info@proxrad.com.

Section titled “Related pages”