Why a 60-day trace window pushes teams to a self-hosted Honeycomb alternative for longer trace retention
If an audit, incident review or compliance requirement asks for traces older than 60 days, the answer is usually to keep trace data in a self-hosted backend that the organization controls. Self-hosted SigNoz or a Grafana trace stack on object storage you own can hold traces for a retention period you set, rather than the window Honeycomb applies by default. Honeycomb keeps events for 60 days, and longer retention is sold as an Enterprise add-on, so the limit is set by the contract and not by your own policy. That matters when a regulator, internal auditor or post-incident review asks what a service did three or six months ago.
The short answer depends on two things: how much telemetry you store and who will run the stack. Storage cost grows with span volume multiplied by the retention period, so a team that retains everything for a year needs a very different storage plan from one that keeps a sampled subset. Confirm your current span volume per day, the fields you index and the period each audit or review actually requires, since many requirements call for a specific subset of services or a shorter window than teams assume. Also confirm which team will own upgrades, backups and capacity, because a self-hosted trace store is only as good as the people operating it.
Before you commit, run a short test. Send the same OpenTelemetry data to Honeycomb and to a self-hosted candidate for a defined period, then check that the candidate answers the questions your auditors or incident reviewers will ask. Record the storage growth you observe, confirm that retention settings take effect as documented, and ask your vendor or implementation partner for a written estimate covering storage, compute, staffing and support. Those measurements, not a generic comparison, will show whether the longer window is worth the operating effort in your environment.
What a longer trace retention requirement asks of the backend
A retention period longer than 60 days changes the backend from a hosted event store into a system you operate. Each requirement below turns the retention need into a decision about storage, access, query history and evidence, and each one has a specific check to run before you choose SigNoz or a Grafana stack.
Retention period set by policy
Retention should follow the period your incident review, audit or compliance policy requires, not the period a vendor plan includes. In SigNoz, trace retention is governed by settings on the storage layer, and because data lands in ClickHouse, the storage you provision sets how long history can realistically stay online. Ask your compliance lead to write the retention period down first, then size the disks or object storage tier against span volume. Confirm with SigNoz how retention is configured in the version you deploy.
Data held in your environment
Self-hosting means trace data, which often carries service names, user identifiers and request metadata, stays in the cloud account, data center or network you control. SigNoz runs on Docker Standalone, Docker Swarm or Kubernetes with Helm, so the placement decision is yours. Grafana also runs as packages, Docker images or Helm charts. Document where the OpenTelemetry Collector, ClickHouse and Grafana databases sit, and confirm that backups and replicas follow the same boundary.
Production state database for Grafana
Grafana stores dashboards, users and alerting state in a database. SQLite is the default, but the Grafana installation docs state it does not scale for production, so MySQL 8.0 or later or PostgreSQL 12 or later is required for production and high availability. Treat this database as a backup target in its own right, because losing it means losing dashboards and access configuration even when the trace data survives. Plan its backups and restore tests alongside the trace storage.
Queryable history for incident review
Keeping traces is only useful if an engineer can still find a specific request from weeks earlier during a post-incident review. Check that the query path works on old data, not only on recent spans, and that dashboards and saved queries referencing older time ranges still load. SigNoz supports its Query Builder, PromQL and ClickHouse SQL, which gives reviewers more than one way to reach historical records. Test these queries against a restored copy before you rely on them.
Access control and exports for auditors
Auditors usually need read-only access to specific evidence, not general administrator rights. In Grafana, SAML, team sync and SCIM provisioning are available only in Grafana Enterprise and Grafana Cloud, so an open-source deployment needs a different approach to role mapping and deprovisioning. SigNoz lists SAML only on its Teams and Enterprise plans. Decide which roles auditors receive, how access is removed, and how exported trace extracts are logged and stored. Confirm current SSO options with each vendor before you commit.
Which open-source options hold traces longer than Honeycomb
This table compares self-hosted options for keeping traces beyond Honeycomb's 60-day window, with the retention mechanism and trade-offs for each. Retention depends on your storage design, so confirm backend support for your chosen object storage before committing.
| Option | How it meets the retention constraint | Trade-offs |
|---|---|---|
| SigNoz self-hosted (MIT core) | Traces are written to ClickHouse on your own servers, so retention is set by your storage capacity and retention configuration rather than a hosted plan limit. | Community Edition has no SAML and support is community Slack only. Storage growth, ClickHouse sizing and upgrades fall to your team. |
| SigNoz Enterprise self-hosted | Same ClickHouse-based retention on your infrastructure, with enterprise support available under a separate commercial agreement. | Enterprise licensing covers code under the ee/ and cmd/enterprise/ directories. Confirm the license terms and support scope in writing. |
| Grafana with Tempo on object storage | Tempo stores trace blocks in object storage, so retention is governed by bucket capacity and the compactor configuration you set. Confirm current Tempo retention settings for your version. | Grafana is AGPL-3.0-only, so review obligations with counsel. SAML and team sync are Enterprise features. Stateful components need operational care. |
| Jaeger with object storage backend | Jaeger, which is Apache-2.0 and a graduated CNCF project, can persist spans to a supported storage backend. Confirm which backends your Jaeger version supports for long retention. | Jaeger is a trace backend only, so metrics and dashboards come from Prometheus and Grafana. Search and query performance over long history needs testing. |
| Grafana Enterprise or Grafana Cloud | Hosted or licensed options can extend retention under commercial terms rather than your own storage. | Grafana Cloud is hosted, which moves data out of your infrastructure. Enterprise tier pricing starts with a stated minimum commitment on the Grafana pricing page. |
What longer trace retention costs in storage and who pays for it
Keeping traces longer than 60 days is a storage and operations decision, not a license line item. When you self-host SigNoz, the SigNoz OpenTelemetry Collector writes spans to ClickHouse, so the bill splits into disk or object storage, the compute that runs ClickHouse and the collector, backups of the stored data, and the people who upgrade and operate the stack. The software itself is MIT-licensed outside the enterprise directories, so you pay nothing per GB for the Community Edition, but your infrastructure account and your staff time carry every recurring cost. Storage grows with the retention window, so doubling the window roughly doubles the data kept on disk, while compute and staff costs change more slowly. Ask your team to size retention by the question you need to answer (for example, how long an incident review must reach back) rather than by a round number.
For a hosted comparison, SigNoz Cloud's Teams plan lists logs and traces at $0.30 per GB ingested with 15-day retention, according to the SigNoz pricing page. Retention beyond 15 days on that plan is a different price point, so ask SigNoz for the retention tier and cost that matches your audit period before comparing it with your own storage. Grafana Enterprise and Grafana Cloud carry their own commercial terms, so for a Grafana stack you would price object storage for Loki or Tempo data separately from any Grafana Cloud quote. Remember that Honeycomb's 60-day window is part of its plan structure, so the comparison should use the retention you actually need, not the one you are leaving.
Four drivers push storage up: span volume, attribute cardinality, sampling rate and the retention window. High-cardinality attributes such as user or request identifiers are what make Honeycomb-style querying useful, and they also make the stored data larger, so test a representative week of traffic before you commit to a window. Sampling is the main lever you control, since tail-based or head-based sampling can cut volume while keeping error and slow traces. In your quote request, ask for the assumed ingest rate per day, the compression ratio used, the retention window, the backup schedule and the named staff effort for upgrades, and confirm each item against your own environment before you accept any figure.
How to deploy SigNoz or Grafana with object storage for longer retention
This sequence takes a team from sizing its trace volume to a self-hosted SigNoz or Grafana stack that keeps traces beyond Honeycomb's 60-day window, with dual shipping, access control, as-code dashboards and a tested backup and upgrade routine.
Size span volume and the retention window
Before choosing hardware, export a representative week of span counts and average span size from Honeycomb or your collector metrics, then decide how many days you need for audit, incident review or compliance. Multiply daily volume by retention days to estimate storage, and add headroom for growth and indexes. Ask your storage and database specialists to validate the figures against your own environment. Done when you have a written volume and retention number that the security and compliance owners have signed off.
Choose the installation method and backend
Pick a deployment method for your platform team: SigNoz supports Docker Standalone, Docker Swarm and Kubernetes with Helm, so Kubernetes is the usual choice where you already run clusters. For Grafana, plan for a MySQL 8.0 or later or PostgreSQL 12 or later database for configuration, because the installation docs state SQLite does not scale for production or high availability. Confirm the object storage target your ClickHouse or Grafana backend will use. Done when the architecture is written down and reviewed by the platform owner.
Deploy the stack in a non-production environment
Install SigNoz from its self-host guide or Grafana from its installation packages, Docker images or Helm charts, in a staging environment inside your own accounts or data center. Check that the collector, query API, frontend and alerting components start cleanly and that the backing database is reachable. Verify the version you deploy against the official releases page and record it. Done when a test trace sent by hand appears in the UI and the components report healthy.
Dual-ship OpenTelemetry data during cutover
Add a second exporter to your OpenTelemetry Collector so that the same OTLP spans go to Honeycomb and to the self-hosted backend in parallel. Keep the Honeycomb exporter in place until the new backend has collected enough history to cover your audit window. Confirm that sampling and attribute processing match on both paths so the data is comparable. Done when spans from production services are arriving at both backends and a sample query returns matching trace IDs.
Set storage, retention and sizing
Configure retention in the backend to match the window agreed in the first step, and set storage capacity and any object storage settings for the trace data. Run a load test with production-like span volume to confirm that query latency and ingest hold at your expected size. Record the retention settings, storage growth rate and the owner of each setting. Done when a test run at expected volume completes and the retention configuration is documented in your runbook.
Secure access with SSO and role controls
Connect the instance to your identity provider. SigNoz lists SSO on every plan, while SAML is available only on its Teams and Enterprise plans. Grafana's open-source edition supports LDAP, generic OAuth, Entra ID, Okta, GitHub, GitLab and Google OAuth, but SAML and SCIM require Grafana Enterprise or Grafana Cloud. Apply the Grafana security hardening recommendations for cookies, Content Security Policy and metrics endpoint authentication. Done when a test user signs in through SSO and an unauthorized account is refused.
Provision dashboards and alerts as code
Store dashboards, data sources and alert rules in version control rather than only in the UI. In Grafana, use the provisioning files loaded at startup, and consider Terraform or Git Sync as documented options. For SigNoz, export dashboard definitions and keep them in the same repository. Review changes through pull requests so that incident review boards survive a rebuild. Done when a clean instance built from the repository reproduces the dashboards and alerts.
Set up backups, upgrades and cutover
Schedule backups of the configuration database, ClickHouse or other trace storage, and the object storage bucket, then test a restore on a separate host. Plan an upgrade routine using the release cadence in the upgrade guidance, where Grafana patch releases come at least monthly and each minor release has a 9-month support window. Once restores and retention checks pass, stop the Honeycomb exporter and keep read access for the agreed period. Done when a restore test succeeds and the upgrade and backup owner has signed the runbook.
What auditors and incident reviewers ask to see for retained traces
Once traces are kept longer than Honeycomb's 60 days, the retained store becomes a system that auditors and incident reviewers can ask about. The cards below cover the evidence they usually request, and each one maps to a setting, record or log you own in a self-hosted stack. DeployOpen prepares this evidence, but auditors and certification bodies draw any conclusion.
Documented retention settings and policy
Auditors will ask what is kept, for how long, and who approved it. Write down the retention period for each signal type (traces, logs, metrics) and the reason for each period, such as incident review or a contractual obligation. In SigNoz, retention is set per signal in the platform configuration, and in a Grafana stack it is set in the backend that stores traces. Record the setting values, the change history and the approver, and check that the running configuration matches the written policy.
Access control and SSO configuration
Reviewers want proof that only approved people can query retained traces, because span attributes can carry user identifiers or request payload fragments. Document which roles exist, who holds them, and how sign-in is enforced. SigNoz lists SSO on every plan including Community, with SAML on Teams and Enterprise. Grafana's SAML, team sync and SCIM provisioning are limited to Grafana Enterprise and Grafana Cloud, so confirm which features your chosen edition includes before you promise them.
Backup and restore test records
A retention promise is only as good as your ability to recover the data. Keep backup schedules for the ClickHouse data in SigNoz or the object storage bucket used by a Grafana backend, along with the configuration and database used by Grafana itself. Most important are dated restore tests that show a sample of older traces came back readable, with the time taken and any gaps recorded. Ask your team to confirm the exact backup tooling for your storage layer before writing it into the evidence pack.
Change records for upgrades
Reviewers expect a dated trail of platform changes. For SigNoz, keep the release tags you deployed and the changelog entries you reviewed, starting from the v0.146.0 release published on October 14, 2026. For Grafana, track which minor and patch versions you run. Grafana's upgrade guidance says patch releases come at least monthly and each minor release is supported for 9 months, so a dated cadence of patch upgrades is easy to show. Link each change to a ticket and a test result.
Audit logging of queries
Access to retained traces is itself a sensitive event, so reviewers ask who queried what and when. Confirm whether your SigNoz edition and your Grafana edition record query and login activity, and where those logs go. If the platform does not record queries natively, capture reverse-proxy or identity provider logs and send them to a separate store that the platform administrators cannot edit. Ask the vendor or community maintainers to confirm the exact audit events each edition emits.
Scope of data held
Auditors will want a data inventory: which services send traces, which attributes are captured, and whether personal or regulated data appears in span fields. Map each service to its OpenTelemetry pipeline and list the attribute keys that are dropped or masked before storage. Note the regions and storage locations used, and the storage and data center choices if you run SigNoz Cloud or a managed option instead of your own servers. Update the inventory whenever a new service is instrumented.
Questions teams ask before moving trace retention off Honeycomb
How much storage does longer trace retention need?
Storage grows with the number of spans you keep, the size of each span, and the number of days you retain them. The main drivers are span volume per second, average span size (attribute count and value length matter most), how many attributes you index, and any replication you configure for durability. If volume stays steady, extending retention from 60 days to a longer window increases raw data in proportion to the number of days. ClickHouse compression lowers the footprint, but the ratio depends on your data. Run a pilot with production-like traffic for at least one representative period, measure the bytes per day, then size the disks and object storage from that measurement. Ask your engineers and any implementation partner to write that method down as part of the scope.
Can our team run longer trace retention without outside help?
Many teams can, if they already run Docker or Kubernetes and have an owner for the observability stack. SigNoz documents installation with Docker Standalone, Docker Swarm and Kubernetes with Helm. Ongoing work includes the OpenTelemetry Collector, ClickHouse storage, scaling, upgrades and backups. The SigNoz Community Edition is free to self-host, but its support is community Slack only, so production incidents rely on your own staff. Outside help is an option. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted platforms inside your own infrastructure, under fixed-scope written agreements, and offers retainers for ongoing support. Assess your in-house skills in ClickHouse, Kubernetes and on-call before choosing between the two paths.
How long does a Honeycomb to SigNoz cutover take?
No duration is fixed in advance. The length depends on how many services send telemetry, how far they are instrumented with OpenTelemetry, how many boards, triggers and SLOs you must recreate, and how long you keep both backends receiving data. Honeycomb ingests OpenTelemetry, so the engineering work is mostly repointing exporters, adjusting Collector configuration and validating that spans arrive with the same attributes. Plan for a parallel run so history builds up in the new backend before Honeycomb is retired. Ask for a written inventory of services, exporters, dashboards and alerts, and agree on the validation criteria before work starts. Engineers will need access to deployment pipelines, the Collector configuration and the on-call rotation.
Does SigNoz Community Edition support SSO or SAML?
SigNoz lists SSO on every plan, including Community Edition, but SAML is available only on the Teams and Enterprise plans, according to the SigNoz pricing page. If your identity provider requires SAML, the Community Edition does not meet that requirement as listed. Confirm the exact protocol your identity provider supports, such as OIDC or SAML, and check whether the SSO option included in Community covers your login flow and user provisioning needs. The same pricing page states that the Community Edition does not include SOC 2 or HIPAA compliance, so review those points with your compliance lead as well. Ask SigNoz to confirm these capabilities in writing for the specific edition and version you plan to run.
Is Grafana Enterprise required for SAML login?
Yes, if you need SAML. Grafana's authentication documentation states that SAML, team sync, active sync and SCIM provisioning are available only in Grafana Enterprise and Grafana Cloud. All editions support LDAP, generic OAuth, Entra ID, Okta, GitHub, GitLab and Google OAuth, auth proxy and JWT. If your policy accepts an OAuth or OIDC integration with your identity provider, the open-source edition may cover your needs. Grafana Enterprise is offered as a non-AGPL commercial option. Grafana's pricing page lists a minimum commitment of 25,000 US dollars per year for its Enterprise tier on Grafana Cloud. Confirm with Grafana which edition, license terms and support level fit your organization before you commit to a design.
Can we export our Honeycomb data before we leave?
Honeycomb events expire after 60 days, so data older than that window will not be available in Honeycomb. The practical step is to dual-ship OpenTelemetry data to the new backend now, so history accumulates there while Honeycomb is still in use. Whether Honeycomb offers a bulk export or query API depends on your plan, so confirm the export options and the returned formats in writing before cutover. Boards, triggers and SLOs have to be recreated in the new tool, so export their definitions manually and keep a record of their thresholds and owners. Review your contract for any data handling terms that apply when you stop using the service.
How does SigNoz Cloud pricing compare with self-hosting for longer retention?
SigNoz Cloud's Teams plan starts at $49 a month including $49 of usage, with logs and traces at $0.30 per GB ingested and 15-day retention, according to the SigNoz pricing page. Longer retention is not described in that tier, so ask SigNoz what retention the Teams and Enterprise plans include. SigNoz Enterprise starts at $4,000 a month and can be self-hosted with enterprise support, where your team runs infrastructure, storage, scaling, upgrades and backups. Self-hosting costs are the storage bill, compute, the staff who operate the system and any implementation work. Ask for a quote that separates one-time setup from recurring storage, support and operations, and check the daily ingest from your pilot against each option.
What changes for on-call engineers and what stays the same
The instrumentation stays put. If your services already export OpenTelemetry traces, the application code, span names and attributes do not need to change when the backend moves to SigNoz or a Grafana stack. What changes is the exporter endpoint in the OpenTelemetry Collector or SDK configuration, which is where on-call engineers should expect to see the first differences. Before the cutover, confirm with the team that owns your Collector configuration which pipelines send to Honeycomb today, and whether any Honeycomb-specific headers or dataset settings are in use. Those are the settings that will not carry over unchanged.
The query habits are where the learning curve sits. SigNoz offers its Query Builder, PromQL and ClickHouse SQL for dashboards, so on-call engineers can keep building filters and group-bys visually while the teams who write complex queries can use SQL against the trace store. Grafana takes a different route: data sources, dashboards and alerting resources can be defined as YAML or JSON files loaded at startup, and Grafana documents further as-code options including Terraform and Git Sync. The practical decision is which of these will be the source of truth for boards and alert rules, because a dashboard edited by hand in the UI is harder to recreate after an incident than one stored in version control. Run a short exercise with your on-call rota that replays a recent incident against the new backend before anyone depends on it at 3 a.m.
Alerts and SLOs need the most attention, because a missing or duplicated notification is the failure on-call teams notice first. In SigNoz, Alertmanager handles deduplication, grouping and notification, so review how those routes map to your current paging tool. In Grafana, the high availability documentation notes that alerting needs additional configuration to avoid duplicate notifications, so plan that setting explicitly if you run more than one Grafana server. Keep the old Honeycomb triggers running alongside the new ones until each alert has fired in a test window and reached the right people, and confirm which SLO definitions you can recreate exactly and which need reinterpretation.
Where to confirm retention, licensing and release details
This sequence gives your team a verified record of which SigNoz and Grafana terms, versions and install paths apply before you commit to storage sizing or a migration. Each step ends with a written check that someone on your side can point to.
Confirm the SigNoz license scope
Open the SigNoz LICENSE file and record which directories fall under the MIT license and which fall under the separate enterprise license in ee/LICENSE. Your legal or procurement lead should own this review, since the answer determines whether the features you need sit in the Community Edition or in a paid tier. Done when the team has a short written note listing each feature it depends on and its license path.
Check the SigNoz self-host install options
Read the SigNoz self-host installation docs to confirm which deployment method fits your environment: Docker Standalone, Docker Swarm or Kubernetes with Helm. Your platform engineering lead should match the method to existing infrastructure and note which storage components the install creates, since ClickHouse holds the trace data that drives your retention. Done when the chosen method and its storage dependencies are written into the design record.
Verify the current SigNoz release
Compare the release you plan to deploy against the SigNoz GitHub releases page, reading the publication dates and release notes for any changes to retention settings, storage behavior or ClickHouse requirements. The owner is the engineer who will run the upgrade path. Done when the team has recorded the version it will pin and the date it was checked, and has confirmed the release notes contain no open question for the design.
Review Grafana licensing for your use
Read the Grafana licensing page to understand the 2021 move of Grafana, Loki and Tempo to AGPLv3, and how plugins, SDKs and agents carry other licenses. Legal counsel should decide whether AGPL obligations apply to how your organization will modify or expose Grafana, and whether Grafana Enterprise is needed for features such as SAML. Done when counsel has signed off on the license posture in writing.
Plan Grafana installation and high availability
Use the Grafana installation docs for package and Helm options, and the high availability guide to confirm that production needs MySQL 8.0 or later or PostgreSQL 12 or later, not SQLite. The platform team should also confirm how alerting avoids duplicate notifications across nodes. Done when the database choice and the alerting configuration are documented and reviewed.
Confirm the retention and storage model
Ask the SigNoz and Grafana vendors, in writing, how each stores traces for longer periods, which retention settings control deletion, and what object storage or ClickHouse capacity each setting requires. The owner is the observability lead, working with finance to convert the answers into a storage estimate in your own environment. Done when the vendor answers and the sizing assumptions are attached to the decision record.
Record the decision and open questions
Collect the license notes, release version, install method, database choice and retention answers into one decision record, and list any item still unresolved with a named owner. Your CISO or CIO should approve the record before any dual-shipping of telemetry begins. Done when the record is signed off and every open question has an owner and a date set by your team.
How DeployOpen deploys long-retention tracing in your environment
DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source observability platforms inside your own cloud accounts, data centers or air-gapped networks. For longer trace retention, that means a self-hosted SigNoz or Grafana stack fed by OpenTelemetry, with storage sized to the retention window your audit or incident review requires.
How we scope
- Written scope lists which services, trace sources and retention periods move off Honeycomb.
- We confirm the retention window your audit, incident review or compliance owners require.
- Scope sets where storage lives, who operates ClickHouse or object storage, and who approves changes.
How we build
- We deploy SigNoz or Grafana with Prometheus and OpenTelemetry Collector pipelines in your environment.
- We configure storage and retention settings so trace history persists beyond Honeycomb's 60 days.
- We test ingestion, query performance, alert routing and access controls against the agreed scope.
How we hand over
- You receive documentation covering deployment, retention settings, storage sizing and access roles.
- We run a dual-shipping period so history builds up in the new backend before Honeycomb is retired.
- Runbooks cover upgrades, backups and restore tests for the trace store your team will operate.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Pricing follows from the written scope, and we confirm storage and operating costs with you before quoting.
