iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
If Loki storage keeps growing after you set a retention period, first check whether the Compactor is actually enforcing it. Loki does not automatically remove old logs: active retention depends on a running Compactor, supported index schema, enabled retention, and a configured deletion store. Even when those are correct, chunk removal is delayed, so verify Compactor activity before treating rising storage as a retention failure.
Grafana’s documentation pages are labeled “latest” and configuration details can vary by release. Check the documentation matching your deployed Loki version before changing production settings.
1. Enable the mechanism that enforces retention
A value in limits_config.retention_period defines a policy; it does not activate deletion on its own. Loki retains logs indefinitely by default unless retention is enabled. Retention is performed by the Compactor, not by the object store automatically. Grafana states, “Retention in Grafana Loki is achieved through the Compactor.” Grafana Labs’ retention documentation describes the mechanism.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Check that compactor.retention_enabled is true, that the Compactor process is running, and that compactor.delete_request_store is set to the configured backend required for retention. Confirm the field names and supported values against the documentation for your Loki release.
#1 Best Overall
2. Confirm that your index schema supports Compactor retention
Current Compactor-based retention requires a 24-hour index period with supported TSDB or BoltDB Shipper indexes. The Compactor does not support retention on legacy index types. TSDB is the recommended current index path; the Table Manager route is deprecated, so avoid transplanting a legacy Table Manager configuration into a new deployment.
Inspect the schema configuration used for the data you intend to expire, not just the newest schema entry. Grafana’s retention guidance and schema documentation describe the supported setup.
3. Choose an intentional global retention baseline
Set limits_config.retention_period to the period your organization actually needs, taking account of audit obligations, incident-response needs, and contracts. If the global period is omitted, its default is 0s, which means logs are kept indefinitely. There is no universally appropriate duration: the right value depends on the data and requirements. See Grafana’s retention configuration.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemsRank #2
- ACTIVITY LOG NOTEPAD FOR WORK – Structured activity log book and time log designed as a work log and task tracker with expanded tracking space
- TRACK WORK WITHOUT RELYING ON MEMORY – Use this work log, time log, and task tracker to maintain detailed workflow records and accountability
- TIME TRACKING LOG FOR WORK, PROJECTS & CLIENT TASKS – Track workflow and tasks using a structured productivity planner and task tracker format It also works as an activity log notebook, call log notepad, time tracker notebook, and employee activity log for detailed work records.
- ANALOG TIME TRACKING THAT WORKS – Written tracking improves recall, reduces errors, and increases execution accuracy
- STRUCTURED TIME & TASK LOGGING SYSTEM – Organized layout provides clear tracking for workflow, tasks, and time entries
4. Shorten retention selectively for streams or tenants
A single global period is simple, but it may keep high-volume, low-value data as long as more important logs. Loki also supports stream-specific retention_stream policies and tenant overrides. Use them to distinguish retention by validated labels or tenant rather than shortening the baseline for every log.
- Stream rules: A selector matches streams by labels, and each rule’s period must be at least
24h. - Precedence: Among matching stream rules, the higher numeric priority wins. If priorities tie, the shorter period is selected.
- Tenant overrides: Per-tenant settings let operators vary policy by tenant; check the relevant tenant configuration and version-specific behavior before rollout.
Test selectors against the labels actually present in your streams and check which rules match before applying a shorter period. A mistaken selector or priority can expire more data than intended. The policy options and precedence are documented in Grafana’s retention guide.
5. Account for delayed deletion and persistent markers
Retention does not remove every chunk at the moment it crosses the configured age. The Compactor first rewrites index references and records chunks for deletion in marker files. The sweeper removes marked chunks after retention_delete_delay. That delay gives index gateways time to refresh and leaves a window to recover from an incorrect policy.
Marker state must survive restarts. Keep local marker files on persistent storage, or configure the object-store marker prefix as appropriate for your deployment. The current configuration reference documents a default retention_delete_delay of two hours; confirm the default for your Loki version. See retention operation details and the configuration reference.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
6. Remove unsafe bucket-wide lifecycle expiration
Object-store lifecycle rules expire objects by age; they cannot tell whether Loki’s index still references a chunk. A broad rule on the Loki bucket can therefore remove data Loki still needs, or delete index objects, delete-request state, marker state, and other required objects. Grafana says Compactor retention is sufficient for most deployments without lifecycle cleanup.
If you add lifecycle expiration as a safeguard, verify the exact chunk prefixes for your schema and tenant layout. Scope the rule only to those verified prefixes, and set its expiration later than Loki retention plus retention_delete_delay. Do not apply blanket expiration to the bucket. See Grafana’s lifecycle and retention guidance.
Rank #4
![DeskFX Free Audio Effects & Audio Enhancer Software [PC Download]](https://m.media-amazon.com/images/I/41fXbDohyuS._SL160_.jpg)
- Transform audio playing via your speakers and headphones
- Improve sound quality by adjusting it with effects
- Take control over the sound playing through audio hardware
7. Verify Compactor work and identify the storage mode
A configured period is not proof that data is being removed. Check the Compactor logs for activity and errors, then inspect the operation counters identified in Grafana’s troubleshooting guide:
loki_boltdb_shipper_compact_tables_operation_totaltracks compaction runs.loki_compactor_apply_retention_operation_totaltracks retention runs.
If retention is not progressing, check the schema and 24-hour index period, retention enablement, whether the Compactor is running, the configured delete_request_store, and deletion lag due to the delay and sweeper. Grafana’s troubleshooting page addresses the direct question, “Why isn’t my log retention policy deleting old data?” at Loki troubleshooting.
Also confirm whether chunks are stored in object storage or on a filesystem. Loki does not delete filesystem chunks just because disk free space is low; filesystem capacity incidents require separate disk-management measures. Rising usage alone does not establish a retention fault: ingestion volume, pending deletion, and storage mode all affect what you see.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Illustrative configuration shape
This is an outline, not a universal production configuration. Replace the example backend and policy with values appropriate to your deployment, and validate every field against your Loki release.
limits_config:
retention_period: 336h
# Optional targeted rules after validating labels and precedence:
# retention_stream:
# - selector: '{namespace="dev"}'
# priority: 1
# period: 72h
compactor:
working_directory: /data/loki/compactor
retention_enabled: true
delete_request_store: <configured-object-store>
retention_delete_delay: 2hThe 336h global period and 72h stream period are illustrative durations, not recommendations. The example’s delay is shown explicitly; verify the applicable default and supported configuration for your version.
What determines whether storage costs fall
Correct retention removes eligible data over time, but no fixed savings percentage follows from the configuration alone. The result depends on ingestion volume, retention periods, compression, backend pricing, and how much data is still within its retention window or awaiting deletion. Measure usage and costs in your own environment after verifying that retention operations are succeeding.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
