Why Graylog index rotation and retention planning comes before the first log arrives
Index rotation and retention decide how long Graylog keeps your logs and how much disk the platform needs, so they should be settled before the first message arrives. A team routing logs into Graylog needs two answers early: how many days of data must be searchable, and how much storage that requires at the daily ingest it expects. Both answers shape the index sets, the rotation settings and the storage tier, and they are much harder to change once data is flowing. Graylog stores messages in indices, and indices are grouped into index sets. Each index set has its own rotation strategy, which decides when Graylog closes the active index and starts a new one. Rotation can be triggered by message count, by index size or by elapsed time. Retention then decides what happens to old indices, and in Graylog Open the strategy is to delete the oldest indices once the configured limit is reached. A separate index set per log type, such as firewall, application or authentication logs, lets each stream have its own retention window and rotation rules instead of sharing one policy across unrelated data. Changes after go-live are costly for several reasons. Changing an index set's rotation or retention affects new indices, but data already written keeps the old settings, so the effect is gradual and easy to misjudge. Moving a stream to a different index set, reshaping fields that the team later wants to query, or reclaiming disk that was sized too small can all require reindexing, downtime or a storage expansion. Confirm with your own environment and the current Graylog index model documentation exactly which settings apply to existing indices before you change them in production. Storage sizing depends on two inputs that the team should measure rather than guess: average daily ingest per log type and the retention length in days. The Graylog system architecture guidance advises calculating log storage as daily ingest multiplied by retention days and then multiplied by 120 percent, and it recommends sizing the message journal at 3 to 5 times daily ingest on SSDs. Ask your team to measure current volume from the sources that will send logs, and add a margin for growth and for log types you have not yet onboarded. Retention is also where the editions differ. Graylog Open handles retention by deleting the oldest indices, which is simple but means data beyond the window is gone from the platform. Graylog Enterprise adds data tiering and a data lake with archive restore, which the pricing page presents as a way to keep older data and bring it back when needed. Decide before go-live whether you need deletion only or a longer, restorable history, because that choice affects both the platform edition and the storage design. Confirm current feature details with Graylog, since the editions and their capabilities change over time.
Which Graylog components decide how long logs live and where they sit
Retention in Graylog is not one setting. It is the result of how streams route messages, which index set receives them, how that index set rotates and expires data, and which storage layer holds the result. Each component below controls part of that chain, and each has a different owner.
Index sets
An index set is the container that decides where a group of messages is stored and how long it is kept. Each index set has its own shard count, replica count, rotation strategy and retention strategy, so one index set per log type or compliance class is the common pattern. Check which index set each source lands in before adding retention rules, because changing an index set later affects only new indices. The security or platform lead who owns retention policy should approve index set design.
Indices and rotation strategy
Indices are the physical units that Graylog creates within an index set, and rotation decides when a new index is started. Graylog supports rotation by message count, by index size or by time, and the right choice depends on daily ingest and query patterns. Confirm the rotation trigger against your expected daily volume so that indices are neither tiny nor large enough to slow searches. The platform engineer running the cluster should own rotation settings.
Retention strategy
Retention decides what happens to the oldest indices once an index set reaches its limit. In Graylog Open, the retention strategy deletes the oldest indices, so the retention period is effectively the number of indices kept multiplied by the rotation interval. Map every index set to a written retention requirement before go-live, and confirm with the compliance owner whether deletion is acceptable for each log type. The compliance lead should own retention periods.
Streams and stream routing
Streams decide which messages are sent to which index set, based on rules that match fields in each message. A misrouted stream can send security logs into a short-retention index set or fill a large one with noisy data, and this is one of the most common causes of unexpected storage use. Review stream rules and their order whenever a new log source is onboarded. The team that owns log parsing and pipelines should own stream rules, with the security team reviewing any change to sensitive streams.
Message journal and Data Node or OpenSearch storage
The message journal buffers incoming messages on the Graylog server before they are written to the search backend, so a short storage outage does not immediately lose data. Log storage itself runs on Graylog Data Node or self-managed OpenSearch, and the storage layer sets practical limits on disk, shard layout and replica counts. Size storage from daily ingest multiplied by retention days and a 120 percent headroom factor, and size the journal on SSDs using the 3 to 5 times daily ingest guidance in the Graylog architecture documentation. The infrastructure team should own both, with storage capacity reviewed at least as often as retention settings.
Enterprise data tiering and data lake archives
Graylog Enterprise adds data tiering and a data lake with archive restore, which let older data move out of hot search storage while remaining retrievable. This changes the retention model from simple deletion to tiered retention, and it changes cost, since archived data is not searched at hot-storage speed. Confirm with the vendor which tiering and archive features are included in your edition and what restore times to expect before relying on archives for audit. The security or compliance owner should decide which data is archived, with the platform team owning tier settings.
Which rotation, retention and index set choices fit your log types
This table compares the main Graylog storage choices: how indices rotate, whether log types share an index set, where retention is enforced, and how long data is kept. Read each row for the situations where it fits and the operational cost you accept. The main takeaway is that index layout decisions are hard to reverse, so settle them against your log types and search patterns before ingest starts.
| Choice | When it fits | Operational cost |
|---|---|---|
| Rotation by message count | Log types with fairly even event sizes, where a fixed number of messages per index keeps index contents predictable | Index size varies with message length, so a busy period can produce very large indices that search more slowly |
| Rotation by index size | Log types with large or variable messages, where you want indices capped at a known storage footprint | Rotation can happen mid-burst, so time ranges in a single index may be uneven and harder to reason about during an investigation |
| Rotation by time | Log types with steady daily volume and search patterns built around date ranges, such as daily reporting | Quiet days create small indices and busy days create large ones, so cluster shard counts need checking as volume grows |
| One shared index set | Small estate with few log types and mostly cross-type investigations that need one search across everything | Retention is set for the whole set, so a noisy source can push out data you need from quieter sources sooner than intended |
| Separate index sets per log type | Log types with different retention needs, access rules or volume, such as security events kept longer than debug logs | More index sets to size, rotate and monitor, and cross-type queries must name several streams or sets |
| Delete retention (Graylog Open) | Teams that keep data for a fixed window and accept that older indices are removed when the limit is reached | Deleted data cannot be searched again, so any longer-term need must be met elsewhere before deletion |
| Tiering and archiving (Graylog Enterprise) | Longer retention needs, where older data moves to lower-cost storage and can be restored for investigations | Restores take time and need a defined procedure, and the edition choice is a recurring subscription cost to confirm with Graylog |
| Short versus long retention | Short retention suits high-volume, low-value debug logs, while long retention suits security and audit evidence | Long retention grows storage cost and cluster load at the same ingest rate, so confirm the storage sizing with your Data Node or OpenSearch plan |
How to size Graylog storage from daily ingest and retention days
The sizing rule from Graylog's system architecture guidance is daily ingest multiplied by retention days multiplied by 120 percent. Apply it to each index set separately, because each index set has its own rotation settings and retention period. For every index set, identify the log types it receives, add up their daily volume, and multiply by the number of days that index set keeps data before old indices are deleted. The 120 percent factor adds headroom above raw volume. The result is a planning figure for the Data Node or OpenSearch storage that holds the indices, and your total storage need is the sum across all index sets.
Start by measuring daily ingest per log type, not by counting sources. Pull actual volume for each source over a period that includes weekday peaks, weekends and any batch jobs. Group sources by log type, then map each log type to the stream and index set that will receive it, because routing decisions in your pipelines determine which storage budget each source uses. For sources not yet onboarded, ask the owning team for current volume from its own platform. Note whether each figure is raw or compressed, and whether it reflects the message size before or after parsing, since extractors that add fields change the stored size.
The message journal is a disk-based buffer on each Graylog server node. It holds received messages before they are written to the search backend. Graylog's architecture guidance suggests sizing the journal at 3 to 5 times daily ingest on SSDs. Size it separately from index storage, because it lives on the Graylog server node disks and protects ingestion during backend slowdowns or outages. Each node keeps its own journal, so plan the figure per node and confirm the journal size and location in the server configuration for your installation method. Journal capacity should never be counted as part of index capacity.
Treat the result as a starting estimate. Replica count, compression, field growth from new extractors and index overhead are assumptions to confirm before you commit hardware or cloud storage. Ask Graylog to confirm the replica settings for your Data Node or OpenSearch version and how compression behaves for your message shapes. Then run a test ingest on a representative index set for enough days to observe actual index size per day, and compare it with the rule. Record any gap as a planning risk, and re-check the figures after the first full retention cycle, when rotation has deleted the oldest indices and the steady-state size is visible.
How to configure index sets, rotation and retention in order
This sequence takes a team from an inventory of log types to index sets that rotate and expire as planned. Each step produces a setting or check that the next step depends on, so storage sizing and retention are decided before production traffic arrives.
Inventory log types and daily volume
Start by listing every source that will send logs to Graylog, such as firewalls, applications, identity systems and servers, and record the log type each one produces. For each type, measure or estimate the average data ingested per day from the current source or a sample export, and note peaks such as month-end batch runs. Ask the source owners which fields and retention periods their compliance teams require. The step is complete when you have a table of log type, source, daily volume and required retention, reviewed by the owners who will be accountable for it.
Group log types into index sets
Combine log types that share a retention period, access needs and search patterns into one index set, and keep types with different retention requirements in separate sets. In Graylog, an index set defines the indices that hold a group of messages, so mixing short-lived debug logs with long-lived audit records in one set forces a single retention rule on both. Confirm with the security team which people will search each group, because access should match the grouping. The step is complete when every log type in the inventory maps to exactly one planned index set.
Choose a rotation strategy for each set
For each index set, select how Graylog decides to roll over to a new index: by message count, by index size or by time. Time-based rotation suits steady, predictable sources because each index covers a known window, while size or count limits suit sources with uneven volume so that no single index grows too large. Record the chosen limit and the expected number of indices per day, calculated from the volumes in the first step. Check the saved values in the index set settings in the web interface, and confirm the exact options available in your Graylog version.
Set retention for each index set
Set the retention behavior for each index set. In Graylog Open, retention deletes the oldest indices once the configured limit is reached, so the time a message stays searchable depends on how many indices are kept and how often rotation occurs. Data tiering and archive restore are listed as Graylog Enterprise features, so if you need older logs moved to lower-cost storage and restored later, confirm that edition before you finalize the design. The step is complete when each set shows the retention rule you documented, and you can state in one sentence how long the oldest message remains searchable.
Route streams to the correct index sets
Create or update streams so that each stream sends its messages to the index set planned for that log type. Use inputs and processing pipeline rules to place messages into the right stream on arrival. Send a test message from each source and confirm in search that it appears in the intended index set. The step is complete when a sample from every log type lands in its planned index set, and no messages appear in a default or unintended set.
Size Data Node storage and the message journal
Calculate required storage with the guidance in Graylog's system architecture documentation: daily ingest multiplied by retention days, multiplied by 120 percent. Use the daily totals from the first step, and confirm with your infrastructure team any replication or growth allowances that apply to your storage platform. Size the message journal at 3 to 5 times daily ingest on SSDs, since the journal holds messages while storage or processing catches up. Graylog recommends Data Node as the search backend, and use of OpenSearch 1.x is deprecated. The step is complete when the storage total and journal size are written down and approved by the infrastructure owner.
Apply settings in a test environment
Build the same index sets, rotation, retention and stream settings in a non-production Graylog deployment that runs the same Graylog and Data Node versions as production. Apply the settings with a documented, repeatable method such as the REST API or a scripted import, so that the test and production configurations are identical. If your test environment allows it, lower the rotation and retention limits temporarily so that rotation and deletion happen within a short observation window. The step is complete when the test settings match the documented design field by field.
Ingest representative traffic and confirm behavior
Forward or replay representative traffic for each log type at volumes close to the daily figures from the first step, and let it run long enough to observe several rotations. After each rotation, open the index list in the web interface and confirm that new index names follow the index set prefix and that the oldest index is removed once the retention limit is reached. Check disk use on the Data Node against the sizing estimate. The step is complete when the index list, node storage and search results all match the design.
What makes Graylog retention planning take longer or cost more
This table lists the factors that lengthen Graylog retention planning or add effort, with a practical way to reduce each one. Read it before scoping, so the decisions that set index sets, rotation and retention are made once, in writing, rather than revisited after data has already been ingested.
| Driver | Why it adds effort | How to keep it down |
|---|---|---|
| Number of log types and index sets | Each log type that needs its own index set, rotation setting and retention period is another configuration to design, test and document. | Group sources into a small set of log types with shared index sets, and add a new index set only when retention or access needs genuinely differ. |
| Daily volume and its variance | Storage sizing depends on daily ingest. Spiky sources, such as debug logging or seasonal traffic, make a single average estimate unreliable. | Measure actual daily ingest per source for a representative period, then size against peak days and document the assumption for review. |
| Required retention length per regulation or policy | Each regulation, contract or internal policy may set a different minimum period, and conflicting rules force separate retention classes. | Collect the retention requirements from legal, compliance and security owners before design, then map each one to a named retention class. |
| Number of environments | Production, staging and development often need different retention and index layouts, which multiplies sizing and rotation settings. | Keep non-production retention short and uniform, and reuse the same index set templates across environments. |
| Multi-node Data Node clusters | Replicas, shard layout and node capacity change the effective storage footprint, and cluster behavior must be checked before retention is fixed. | Confirm the cluster topology and storage per node early, and size retention against the cluster you will run, not a single test node. |
| Archive restore or tiering in Graylog Enterprise | Restoring archived data or moving older data to lower-cost tiers adds licensing scope, runbooks and restore testing that Graylog Open does not provide. | Decide early whether historical search beyond the retention window is needed, and confirm which edition provides archive restore and tiering before committing to a design. |
| Stakeholder sign-off | Retention periods affect legal holds, audits, privacy obligations and cost, so each change may need review from several owners. | Agree retention classes and a sign-off list up front, and record approvals so later changes follow a known path. |
How to control access to stored logs and make deletion accountable
Storage controls decide who can read logs, who can shorten how long they are kept, and whether those changes leave a trail. Access to streams and index sets, encryption, the MongoDB metadata store and change records all affect whether retention can remove evidence without an approved, traceable decision. Check each control against your own approval process before you set retention periods.
Role-based access to streams and index sets
Graylog roles decide which streams a user can search and which index sets their messages are stored in. Map each log type to a stream and an index set, then grant search rights only to the teams that need that data. Test that a role cannot read a stream it was not assigned, and confirm which stream permissions apply to saved searches and dashboards built on top of it, since those can expose the same messages.
Who may change rotation and retention
Rotation and retention are index set settings, so any user who can edit an index set can shorten retention or change the rotation rule. Limit index set administration to a small named group and keep day-to-day search roles away from that screen. Confirm which permissions in your Graylog version cover index set editing before you finalize the role model.
Approving retention that removes evidence
Retention deletes the oldest indices automatically, so a shorter setting can destroy data that an open incident, legal hold or regulatory minimum still requires. Name who may approve a retention reduction, the checks they must complete first, such as open cases and holds, and who records the decision. Agree this with legal, compliance and security owners before the change is applied. Ask whether your edition offers an archive to restore from, because deleted indices may not be recoverable.
Encrypting Data Node and OpenSearch traffic
Log data moves from Graylog servers to the Data Node or OpenSearch cluster, moves between backend nodes and then rests on storage volumes. Enable TLS on the connection between Graylog and the search backend and on traffic between backend nodes, following the configuration guidance for your version. Confirm how encryption at rest is provided by your disks, volumes or platform, and document who owns the keys and how they are rotated.
Securing the MongoDB metadata store
MongoDB holds Graylog configuration, users, roles and index set settings, so anyone who can write to it can change retention without using the web interface. Restrict network access to Graylog nodes only, require authentication, encrypt client connections and back up the replica set on a schedule you have tested. Confirm that your MongoDB version is covered by the compatibility matrix for your Graylog release, which lists MongoDB 7.x up to 8.2.x for Graylog 7.0 to 7.2.
Recording changes to retention settings
Accountability requires a record of who changed rotation or retention, when the change was made and what the previous value was. Confirm whether your Graylog version records configuration changes in its own logs, then forward those events to a central store that Graylog administrators cannot edit. Test the trail by changing a retention value in a non-production environment and checking that the record shows the old value, the new value and the user who made the change.
How to verify rotation and retention work and fail safely
Test rotation and retention with known data before you trust them with production logs. The checks should confirm four things: new indices appear at the configured trigger, the oldest indices are removed only after the retention window closes, messages land in the index set they were routed to, and searches still return results across rotated indices. Run these tests on a non-production index set using a test input that sends tagged messages at a known count, such as a GELF or syslog source sending numbered test lines.
Start with rotation. In a test environment, set the index set's rotation strategy (message count, size or time) to a small, known threshold, then send enough tagged messages to cross it. Confirm that a new index is created at the trigger and that the index set's write target moves to it. For retention, record the names and creation times of existing indices before the test, then confirm that no index is deleted before the configured retention window has passed and that the oldest index is removed once it has. Keep exact timestamps so you can compare them with what the Graylog system and index set pages report.
Next, confirm routing. Send messages from each source that should match a stream, then count the tagged test messages in each index. A mismatch usually points to stream rule order, a processing pipeline rule that changes stream assignment, or an index set left as the default. Also confirm that a search spanning several rotated indices returns the same total as the sum of the per-index counts. Run one search across the full retention window and one across a range that crosses a rotation boundary, and check that both return the messages you expect.
The failure test is where planning most often falls short. On a test cluster, fill a dedicated volume or otherwise simulate low storage, then observe what happens. Confirm that messages queue in the message journal on disk while the search backend cannot accept them, and that the journal's disk has room for the backlog you expect. The system architecture guidance advises a journal of 3 to 5 times daily ingest on SSDs, so check that figure against your own volume. Verify that an event definition or notification you have configured fires before the journal or storage is exhausted, and record how the search backend, whether Data Node or OpenSearch, behaves at its own disk thresholds.
Confirm the exact behavior against the documentation for your Graylog version. The current documentation covers version 7.2, and the index model page describes rotation and retention settings, but details such as how retention interacts with index sets, what the interface shows during rotation, and how full-storage conditions appear may differ between releases and between storage backends. Write up each test as a short record: the version tested, the settings used, the expected and observed result, and any manual step required. Repeat the tests after upgrades or after any change to index set settings, since a small retention change can alter which data is deleted.
What to monitor, back up and document after retention is set
This table lists the signals, backups, review triggers and records that keep Graylog index rotation and retention working after go-live, with the owner for each. Read each row as a standing duty: the trigger tells you when to look again, and the owner is the person accountable for acting. Most retention failures show up first as full disks or lost journal data, so start with the monitoring rows.
| Area | What to check | Owner and review trigger |
|---|---|---|
| Disk use per node and index set | Track storage consumed by each index set against the retention you configured, on every Data Node or OpenSearch node. Confirm that rotation and deletion keep pace with ingest. | Platform operations owner. Review weekly, and after any change to daily ingest or to an index set's rotation or retention setting. |
| Journal fill level | Watch the message journal on each Graylog node. A journal that keeps growing usually means the search backend cannot accept data as fast as it arrives. | Platform operations owner. Alert on sustained growth. Review after any increase in log sources or a backend capacity change. |
| Index counts and rotation activity | Check the number of indices per index set and confirm that rotation creates new indices on schedule and that old ones are removed as expected. | Platform operations owner. Review after changes to rotation strategy, such as moving between message count, size or time. |
| Deletion events | Review the audit trail and system logs for index deletions. Confirm each deletion matches a retention rule and that no index set is deleting data sooner than the policy allows. | Security or compliance owner with platform operations. Review monthly and whenever a retention policy changes. |
| MongoDB backup of index set settings | Back up the MongoDB database that stores index set definitions and related configuration. Test that a restore brings back index set settings and rotation rules correctly. | Platform operations owner. Back up on the schedule set by your recovery policy and test a restore after each Graylog or MongoDB upgrade. |
| Retention review on volume or policy change | Recalculate storage needs when daily ingest grows, a new log type is added or a regulation changes the required retention period. Apply the sizing method in the Graylog architecture guidance. | Compliance owner for policy changes. Platform owner for volume changes. Trigger: any new log source, a sustained rise in ingest or a policy update. |
| Upgrade compatibility checks | Before upgrading Graylog, Data Node or OpenSearch, check the compatibility matrix for supported MongoDB and OpenSearch versions. Confirm index sets and retention still behave as expected after the upgrade. | Platform owner. Run the check before every planned upgrade. Watch for deprecation notices, including the planned removal of OpenSearch 1.x support in Graylog 8.0. |
| Retention schedule and owners record | Document each index set, its log type, rotation method, retention period, storage location, deletion rule and named owner. Keep the record with the change history. | Compliance owner signs off the schedule. Platform owner keeps it current. Update within the same change window as any retention change. |
What buyers ask about Graylog retention planning and outside help
How much does Graylog retention planning cost with an outside partner?
The cost is set by the written scope, not by a standard rate, and DeployOpen does not publish a price list. The main drivers are the number of log types that need their own index set, how many environments are covered, whether retention rules must match an external policy, and how many systems must be checked against the sizing rule. Ask for a quote that lists each index set, the retention period per set, the storage backend assumed, and whether test rotation runs are included. Software cost is separate: Graylog Open is free with no volume limits, while Enterprise and Security start at published annual amounts with a minimum of 10 GB per day or 100 Graylog Compute Units, according to the Graylog pricing page. Storage hardware or cloud spend recurs and grows with retention.
How long does a Graylog retention and rotation project take?
Duration depends on how many log sources feed each index set, how much existing storage must be measured, and how many decisions need sign-off from security, legal or compliance owners. A single cluster with a few well-understood log types usually takes less time than a multi-environment estate with mixed retention rules. The schedule should show when daily ingest figures are collected, when rotation settings are tested on a non-production cluster, and when changes go live. Ask for milestones in the written scope so that waiting on approvals is visible. No fixed timeline is given here because it depends on the environment.
What do we need to provide before retention work can start?
Plan to supply measured daily ingest per source or stream, the retention periods your policies require for each log type, a current view of the Graylog and storage layout, and access to a non-production environment for testing. You also need named owners who approve retention periods and deletion behavior. Without measured ingest, the storage estimate is only a guess. Ask the partner to state which of these items it needs in writing, and what happens if a figure is missing when the work begins.
Can our own engineers plan Graylog index rotation without a partner?
Yes, a team with Graylog operations experience can plan index sets, rotation and retention internally. The work is mostly measurement and decision-making: confirming what each log type is, how much it produces per day, and how long it must be kept. The risk lies in mistakes that only appear under load, such as deleting indices earlier than intended or underestimating storage after a volume increase. Internal staff should confirm the rotation and retention behavior on a test cluster before changing production. An outside review is useful when the team lacks time or has not sized storage before.
How do retention options differ between Graylog Open and Enterprise?
In Graylog Open, retention is handled through index rotation and a retention setting that deletes the oldest indices once the limit is reached, so data past the window is removed. Enterprise adds a data lake with archive restore and data tiering, which lets older data move to lower-cost storage and be brought back when needed, according to the Graylog pricing page. Confirm whether your archiving requirement needs restore, how long restore takes, and which storage tier the archived data sits on. Edition choice should follow these requirements and the volume minimum, not the other way around.
How does daily log volume determine the storage we need?
Storage scales with daily ingest and retention. The Graylog system architecture guidance advises sizing log storage as daily ingest multiplied by retention days, then multiplied by 120 percent to leave headroom. For example, an illustrative source producing 50 GB per day kept for 30 days would need 50 × 30 × 1.2 = 1,800 GB before replication or overhead is considered. The message journal also needs 3 to 5 times daily ingest on SSDs, according to the same guidance. Re-run the calculation whenever a log source grows, because a small increase in ingest multiplies across the whole retention window.
Which engineering checks confirm rotation and retention work as intended?
Start by checking that each index set has the intended rotation strategy, whether by message count, size or time, and that the retention action matches the policy. Then confirm that the oldest indices are deleted at the expected point and that search still covers the retention window. Test with replayed or sample data on a non-production cluster, and check disk usage against the sizing formula after several rotation cycles. Confirm that the Data Node or OpenSearch backend has enough capacity for the peak ingest, not only the average. Record the settings so that later changes can be reviewed.
How DeployOpen scopes, builds and hands over Graylog retention work
DeployOpen plans Graylog index rotation and retention as a written, fixed-scope piece of work inside your own infrastructure. We map each log type to an index set, set rotation and retention rules, test them against real ingest, and hand over the configuration with documentation your team can run.
How we scope
- Inventory log sources and measure current daily ingest per source and per log type.
- Define which log types get their own index sets and how long each must stay searchable.
- Confirm the edition boundary: delete-based retention in Graylog Open versus data tiering and archive restore in Enterprise.
How we build
- Configure index sets with rotation by message count, size or time, matched to each log type's volume.
- Set retention so the oldest indices are deleted on a defined schedule, and test that rotation fires as planned.
- Size Data Node or OpenSearch storage from daily ingest, retention days and a 120 percent headroom factor from Graylog's guidance.
How we hand over
- Deliver a written retention matrix listing each index set, rotation rule, retention period and owner.
- Document storage sizing assumptions so your team can recalculate when daily ingest changes.
- Walk your operators through checking index status, rotation events and disk usage on the cluster.
How we support
- Offer ongoing support and upgrades as a retainer, including retention reviews as log volumes grow.
- Review rotation and storage alignment again when Graylog minor releases or compatibility changes affect index handling.
- Confirm with your team which support scope, response expectations and review cadence apply before work starts.
