Skip to main content
Fiddler ships new features rapidly. To maintain a fast development pace and ensure a stable customer experience, we define clear stages for feature maturity. Evolution from one stage to the other is quality-bound, not time-bound. Features evolve through the following stages. Any capability that is not explicitly labeled Private Preview or Public Preview is not a preview. GA is the default: unless a feature’s documentation carries a preview label or a deprecation notice, that feature is covered by your support plan and Fiddler’s SLA, as defined in your agreement with Fiddler, from the day it ships. You never have to infer whether a feature is a preview from its age or how new it looks, and deprecations are always announced in the release notes and called out in the feature’s documentation. How Stages Are Labeled explains why the absence of a preview label is reliable. Because graduation is quality-bound, Fiddler does not publish a target GA date for a preview feature — a feature advances when it meets the bar for the next stage, not when a clock runs out. What Fiddler does commit to is that a preview is never left to drift: every preview feature is reassessed at least every two quarters, and each review ends in a decision to graduate it, re-scope it, or retire it. A preview that has quietly sat unchanged for a year is a bug in our process, not a stage.

​
Stages At A Glance

A feature’s first release is Private Preview, Public Preview, or GA. It can then move through the remaining stages as its support commitment changes. The sections below define each stage in full. Custom Solutions Engineering work sits outside this lifecycle entirely.
To see which Python versions Fiddler’s SDKs support, see the Python version support policy.

​
Generally Available (GA)

The GA stage is when a feature is not only ready for production but the SLA is guaranteed. GA features are fully supported by our team and are backed by our comprehensive support plans, providing customers with confidence in reliability, security, and performance. GA is also the default stage. An unlabeled feature is GA — Fiddler does not ship unlabeled features that carry preview-level support. On-premises: GA features are available in Fiddler Cloud and in on-premises deployments alike. A feature reaches your cluster with the first release your deployment receives that contains it. On-premises releases follow a less frequent cadence than Fiddler Cloud, so check the release notes for the version you run rather than assuming the latest documented behavior. Billing: GA features are billed under your contract, at final pricing. Any change to how a GA feature is metered or priced is a contractual change, handled by your account team.

​
Public Preview

Public Preview features are reasonably mature and ready for broader testing, accessible to all customers. This allows us to gather data about the feature in the wild, including important customer feedback. While not formally bound by our SLA, our team responds promptly to issues. APIs and functionality may—but are not likely to—change. On-premises: Public Preview features ship to on-premises deployments through the normal release train, and carry the same preview label there that they carry in Fiddler Cloud. Some features reach Fiddler Cloud one or more releases ahead of on-premises; when that happens, the release notes say so. Billing: Using a Public Preview feature does not add a separate charge during the preview, unless your contract says otherwise. Pricing is not settled until the feature reaches GA, and the GA price may differ from what you see during the preview. Fiddler tells you before a preview feature you are using becomes billable — a preview feature never starts charging silently.

​
What Public Preview Guarantees

  • The feature is available to all customers, turned on by default.
  • Enabling it does not break or degrade existing functionality, and does not degrade the SLOs that cover the rest of the platform.
  • Its documentation is published on this site and marked as a preview.
  • Breaking changes are minimal and are announced in the release notes. Fiddler also contacts heavy users of the feature directly rather than relying on the release notes alone.
  • Fiddler expects the feature to reach GA. A Public Preview is not a trial balloon.
  • An SLO applies, but no SLA.
  • Public Preview features are ready for production use — the SLO-instead-of-SLA difference above is the one thing to weigh before putting one on a critical path.

​
Private Preview

Private Preview features are early-stage and available to select design partners only. During this stage, no Service Level Agreement (SLA) is provided. Instead, our engineering team collaborates directly with partners to iterate on the solution, making changes as needed based on feedback during business hours. Features, including their APIs, will change rapidly; they might also be abandoned entirely. On-premises: Private Preview features are not guaranteed to be available on-premises. Most are validated in Fiddler Cloud first, and enabling one in an on-premises deployment depends on the release your cluster runs. If you are an on-premises customer interested in a Private Preview feature, your Customer Success Manager will confirm whether it can be enabled for you. Billing: Private Preview features carry no charge and no pricing commitment. Pricing and packaging are among the things design partners help us work out. Why design partners? Having a handful of transparent, engaged users or prospective customers can guide you through your first iteration of the product’s functionality, user experience, pricing and packaging, and more. Their critiques should help you build something useful and usable for your broader customer base. To inquire about private preview features, please reach out to sales@fiddler.ai.

​
What Private Preview Guarantees

  • The feature is off unless Fiddler has enabled it for you, and is offered only to selected design partners.
  • It leaves the rest of the platform unchanged for every customer who does not have it enabled.
  • Once enabled, it may cause unexpected side effects. Do not put a Private Preview feature on a critical path without discussing it with your Fiddler contact first.
  • Its documentation may be published on this site behind a Private Preview label, or shared with you directly.
  • Fiddler’s engineering team supports it directly, during business hours.
  • Breaking changes are communicated to design partners directly, not through the release notes.
  • No SLA and no SLO apply.

​
Deprecated

A Deprecated feature still works and is still supported, but is no longer receiving new investment. Deprecation is announced in the release notes, together with the replacement to migrate to — or, when there is no replacement, the reason the feature is being retired. Customer-facing features typically get at least six months from the deprecation announcement to removal. Fiddler contacts affected customers directly rather than relying on the release notes alone, and the documentation for a deprecated feature points at the supported path for the whole window. Public APIs and SDK methods carry additional guarantees on top of that window. A deprecated public interface emits a deprecation warning at call time and stays backward compatible for the full deprecation window — never less than two releases — so code written against it keeps working until the announced removal.

​
End Of Life (EOL)

At End Of Life the feature is removed from the product. This happens only after the announced deprecation window has elapsed and, where a replacement exists, its migration path is documented. Removal is recorded in the release notes for the version that removes it, so you can confirm the exact release your deployment needs to stay below if you have not migrated yet.

​
How Stages Are Labeled

Every Private Preview and Public Preview feature carries a label on its documentation page — at the top when the whole page describes the preview, or on the specific section when a page documents a previewed capability alongside GA ones. Both labels are rendered from a single shared source, so they read identically everywhere and cannot drift page to page. The set of previewed features is tracked in one registry in the Fiddler repository, and a build check fails if a page’s label and that registry ever disagree — in either direction. A feature cannot be labeled without being registered, and it cannot graduate to GA without its labels being removed in the same change. That two-way check is what makes the default at the top of this page safe to rely on: a missing preview label means the feature is not a preview, not an oversight.

​
Custom Solutions Engineering Work

This is not a maturity stage. The stages above describe how far a Fiddler product feature has matured and what Fiddler commits to as a result. Custom work does not progress through the stages and does not graduate to GA. So while some customers have solutions custom-crafted by our Solutions Engineering Team, these features—while useful and in production—are not officially supported by our overall product SLA. Talk directly with your SE or CSM for clarification as to what SLA any custom-developed tools fall under.