Skip to main content
ImpulseMinio

How to monitor storage usage

Where to find aggregate and per-bucket storage usage, how often it refreshes, and what to do if usage isn't updating.

Last updated 20 days ago

How to monitor storage usage

When you'd do this

You want to see how much storage and bandwidth your customers are consuming, spot a runaway tenant, or sanity-check a billing dispute. ImpulseObjects collects usage on a recurring schedule and exposes it in a few places.

Where usage shows up

  • Servers tab. Each server row shows aggregate used vs. allocated storage, current tenant count, and last-collected timestamp.
  • Customers tab. Each service row shows that customer's storage used, bucket count, and bandwidth used this billing period.
  • Service Module tab in WHMCS. Per-customer detail — per-bucket usage, request counts, and bandwidth split by ingress/egress.
  • Customer client area. The service's client-area page shows the customer their own usage. They don't need to ask you for routine quota checks.

How often it refreshes

Usage is collected by a periodic task that rides on ImpulseCore's cron runner. It typically runs hourly and pushes a row per service into the usage table. The Servers tab and Customers tab read from that table directly, so they're never more than one cron tick stale.

Spot-checking via SQL

For a quick "biggest tenants by storage" query without opening the UI:

SELECT s.service_id, s.bucket_name, u.bytes_used, u.collected_atFROM mod_impulseobjects_services sJOIN mod_impulseobjects_usage u ON u.service_id = s.idWHERE u.collected_at = (  SELECT MAX(collected_at) FROM mod_impulseobjects_usage WHERE service_id = s.id)ORDER BY u.bytes_used DESCLIMIT 20;

For bandwidth over the current billing period, the usage table typically also carries bytes_in and bytes_out columns aggregated daily.

If usage isn't refreshing

The usage refresh depends on ImpulseCore's cron runner. If the Servers tab shows a stale collected_at for every server (not just one), the cron isn't ticking, not the collection task.

  1. Check ImpulseCore's Cron Health. Open Addons then ImpulseCore. The Cron Health table lists every registered task with its last-run timestamp and status. Look for the ImpulseObjects usage-sync task (typically impulseobjects.usage_sync or similarly named).

  2. If the task shows error, click in for the captured exception. The audit log filtered to module=impulseobjects will have the full trace. Common causes: a storage host became unreachable mid-collection, or the admin proxy bearer token drifted.

  3. If the task is pending with a stale timestamp, Core's cron itself isn't firing. Run it manually to test:

    /opt/plesk/php/8.3/bin/php /path/to/whmcs/modules/addons/impulsecore/cron.php

    Replace /opt/plesk/php/8.3/bin/php with your PHP CLI binary. On Plesk: /opt/plesk/php/8.3/bin/php. On cPanel: /opt/cpanel/ea-php83/root/usr/bin/php. On a vanilla LAMP install: /usr/bin/php or whatever which php returns. If usage refreshes after a manual run, the system crontab line is missing or wrong. Add the standard Core cron line and future ticks fix themselves.

  4. For a single stuck server, check the unreachable server article. One unreachable host won't stop usage collection for the others — but it will leave that one server's row stale until reachability is restored.

Was this helpful?

Still need help? Ask the team