Website profiles · Technology insights · Alternatives

langfuse.com Paid content

Categories: Artificial Intelligence

Trace, evaluate, and improve AI agents with one open platform. Use production data to understand behavior, collaborate on fixes, and ship better quality at lower cost and latency.

Visit website

Updated: 2026-09-24 04:58 Language: English (default) Access: Normal

Profile views 4 Outbound visits 1
Langfuse Full homepage screenshot
Editorial Review

Website Review

What is Langfuse?

Langfuse is an open-source platform for tracing, evaluating and improving AI agents and LLM applications. Its core idea is a continuous loop: instrument your app so every LLM call, tool invocation and retrieval step is captured as a trace, then use that production data to run evaluations, test prompt changes in experiments, and ship improvements with evidence instead of guesswork.

Its main pieces, per the product page:

  • Observability — hierarchical traces of LLM calls, tools and retrieval, filterable by user, session, cost, latency or custom metadata.
  • Evaluation — LLM-as-a-judge, heuristic functions or human review, run on production data or inside experiments.
  • Prompt management — prompts kept outside code with one-click deploys and rollbacks.
  • Playground — test prompts against real production inputs and compare models side by side.
  • Experiments and human annotation — define test cases, compare results, and build golden datasets from reviewed traces.
  • Cost and latency monitoring — dashboards and automated alerts.

Who it suits, and the trade-off. It fits teams that already have an LLM feature in production and need to debug it or measure quality changes — the page cites Canva's AI team tracing generative design features, and claims use by 21 of the Fortune 50 with 100,000+ engineers building on it. The page also states it works with any language or framework supporting OpenTelemetry, with native Python and TypeScript SDKs, plus integrations for frameworks like LangChain, Vercel AI SDK and LiteLLM and providers including OpenAI, Anthropic and Amazon Bedrock — so you are not locked into one vendor. The trade-off is that value depends on instrumenting your app properly; a team unwilling to add tracing and define evaluations will mostly get dashboards, not improvement.

Next step: if you want to judge fit quickly, pick one production LLM feature, add tracing to it, and run a single evaluation or prompt experiment on real traffic. If that loop feels useful, compare self-hosting against the hosted option on Langfuse.

How does Langfuse help debug and improve AI agents in production?

Langfuse is built for exactly that loop: capture what your agent actually does in production, then use those traces to test and ship improvements. Its page_evidence describes one integrated platform covering observability, evaluation, prompt management, a playground, experiments, human annotation, and cost/latency monitoring.

The debugging side

Hierarchical traces record every LLM call, tool invocation, and retrieval step, and you can filter by user, session, cost, latency, or custom metadata. In practice, that means when a user reports a bad answer, you can pull the session, see which retrieval step returned the wrong document, and check whether the tool call or the prompt was at fault — rather than guessing from logs. Cost and latency dashboards with automated alerts catch regressions that only show up under real traffic.

The improvement side

Production traces become test material. You can run LLM-as-a-judge, heuristic functions, or human review on live data; define test cases and run experiments comparing results side by side; and test prompts on real production inputs in the playground before deploying. Prompt management separates prompts from code with one-click deploys and rollbacks, so prompt changes don't require a release.

A concrete workflow: filter traces for high-latency sessions, annotate the failing ones into a golden dataset, run an experiment with a revised prompt, compare quality and cost against the current version, then roll out via prompt management and watch the dashboards.

Fit and trade-offs

The page_evidence states it works with any language or framework supporting OTel instrumentation, with native Python and TypeScript SDKs and 100+ integrations, plus agent frameworks like LangChain, Vercel AI SDK, and CrewAI — so there's no framework lock-in. It's open source, which matters if you need to self-host or inspect the internals. The trade-off is scope: it's an observability and evaluation platform, not an agent builder, so you still need your own orchestration and deployment. It's aimed at developers and AI engineering teams; smaller teams may find the full evaluation and experiment workflow more than they need at the start.

If you're evaluating it, start by instrumenting one production agent and tracing a week of real traffic before investing in datasets and evaluators — the traces usually reveal which evaluation approach is worth building. Langfuse's own documentation and Academy are the natural next step; for the broader category, OpenTelemetry explains the instrumentation standard it builds on.

How do I set up Langfuse with my existing AI stack or framework?

Langfuse is designed to slot into an existing stack rather than replace it. There are two integration paths, and which one you pick depends on how much instrumentation control you want.

Path 1: OpenTelemetry (framework-agnostic)

Langfuse accepts OTel-instrumented traces, so any language or framework that emits OTel spans can send data to it. This is the route to take if your stack already has OTel instrumentation or if you want to avoid tying your tracing code to a specific vendor. You point your OTel exporter at Langfuse and traces land in the platform.

Path 2: Native SDKs

For Python and TypeScript, Langfuse provides native SDKs. These give you the most direct control over trace structure — you can nest spans for LLM calls, tool invocations, and retrieval steps yourself, and attach metadata like user ID, session ID, or custom tags for later filtering.

Framework integrations

If you use an agent framework, there is likely a prebuilt integration that handles instrumentation for you, covering frameworks such as LangChain, the Vercel AI SDK, LiteLLM, Pydantic AI, Google ADK, CrewAI, and LiveKit, among others. Model providers like OpenAI, Anthropic, Amazon Bedrock, Azure OpenAI, Mistral AI, and Google are also covered. The practical benefit: you add the integration and get traces without hand-writing span code.

Situation Suggested starting point
Python or TypeScript app, no framework Native SDK
Any other language (Go, Java, .NET, Ruby, PHP, Swift) OTel instrumentation
Using an agent framework The framework's Langfuse integration
Already emitting OTel traces elsewhere Repoint your OTel exporter

A concrete first step

Start with one non-critical path in production — say, a single generation endpoint — and instrument only that. Confirm the trace shows the hierarchy you expect (LLM call nested under the request, tool calls visible as child spans), then expand. Once traces are flowing, the same data feeds evaluation, prompt management, and experiments, so you do not need to re-instrument later.

For setup specifics and current integration docs, see Langfuse. If you are evaluating alternatives alongside it, OpenTelemetry documents the underlying instrumentation standard, and LangChain covers one of the supported frameworks.

How does Langfuse's pricing work for different team sizes?

Langfuse's pricing page is the authoritative source for current tiers and limits, so treat the structure below as a way to think about fit rather than a quote. Langfuse

The main axis is not really team headcount — it is usage volume (observations/traces ingested per month) plus whether you self-host or use the managed cloud. A five-person team generating heavy agent traffic can cost more than a fifty-person team running light prototypes, so plan around event volume first and seats second.

H3 What typically changes across tiers

  • Cloud vs. self-hosted: The open-source core can be self-hosted, which shifts cost to your own infrastructure and ops time. Managed cloud trades that for a subscription based on usage.
  • Usage metering: Observation/trace volume, retention window, and number of projects or environments are the usual levers.
  • Collaboration features: Prompt management, annotation workflows and role-based access tend to matter more as teams grow, not as usage grows.
  • Support and compliance: Larger organizations usually need SSO, audit trails, SLAs or a self-hosted enterprise arrangement.

H3 Matching tier to team shape

Team situation What to weigh
Solo dev / prototype Free or entry cloud tier; self-hosting only if you already run infra
Small product team (5–20) Cloud usage tier; check retention and project limits
Platform team, high traffic Compare cloud usage cost against self-hosted ops cost
Enterprise / regulated Self-hosted or enterprise plan for SSO, security, support

H3 A concrete way to decide Estimate your monthly observations (LLM calls, tool calls, retrieval steps per request × requests), then check that number against the published tier limits and retention. If you are near a boundary, self-hosting often wins on cost but costs engineering time; if your team is small and lacks infra capacity, managed cloud is usually the faster path.

Next step: open the pricing page, plug in your projected monthly observation volume, and compare the cloud figure against an honest estimate of the hours your team would spend running a self-hosted deployment. For related tooling context, see Langfuse and, if you are comparing observability options, OpenTelemetry.

How can I run evaluations and experiments on my AI agents with Langfuse?

Langfuse runs evaluations and experiments on the same production data you already trace, so the loop is: observe real traces, turn interesting ones into test cases, run evaluators, then compare results side by side.

The evaluation path

Langfuse supports three evaluator styles, and you can run them either on live production data or inside an experiment:

  • LLM-as-a-judge — a model scores outputs against your criteria (relevance, correctness, tone).
  • Heuristic functions — deterministic checks such as format validation, keyword presence, or length.
  • Human review — people annotate traces and build "golden" datasets from real cases.

A practical scenario: your agent answers billing questions. You trace every conversation, notice a cluster of traces where retrieval returned nothing, and attach an LLM judge for answer groundedness. Running it over production traces tells you how often that failure actually happens — not just whether the code path executes.

The experiment path

Experiments let you define test cases, run a prompt or model variant against them, and compare results side by side. Combined with prompt management, you can version a prompt, deploy or roll back with one click, and test candidate prompts in the playground against real production inputs before shipping.

A useful decision rule: use production evaluation when you want to know how the current system behaves at scale and catch regressions; use experiments when you have a specific change in mind and need a controlled comparison. Most teams need both, and the value comes from feeding experiment findings back into production monitoring.

What makes this workable

Because tracing, prompts, evals, experiments, and human feedback live in one platform, the artifacts connect: a flagged production trace becomes a dataset item, that item becomes an experiment case, and the experiment result informs the next prompt version. Hierarchical traces capture each LLM call, tool invocation, and retrieval step, filterable by user, session, cost, latency, or custom metadata — which is what makes targeted evaluation possible rather than scoring everything blindly.

Langfuse states it works with any language or framework supporting OpenTelemetry instrumentation, with native SDKs for Python and TypeScript, and integrations across agent frameworks and model providers such as LangChain, the Vercel AI SDK, LiteLLM, OpenAI, Anthropic, and Amazon Bedrock. That matters if you don't want evaluation tied to one framework.

One trade-off worth naming: LLM-as-a-judge evaluators add their own cost and latency, and judge quality depends on how well you write the criteria. Heuristic checks are cheap and stable but shallow. Human annotation is the most trustworthy and the least scalable — reserve it for building golden datasets and resolving disagreements between automated evaluators.

Next step

Start with one high-volume agent behavior, trace it in production for a few days, then write a single LLM judge for the failure mode you see most. Turn the worst traces into a small dataset, run one experiment comparing your current prompt to a revised version, and only then expand to more evaluators. Langfuse's own documentation and Academy cover the setup, and the pricing page is the place to check what fits your volume if you move beyond self-hosting.

What security and data privacy measures does Langfuse provide for production LLM traces?

Langfuse treats security and privacy as a deployment and data-handling question rather than a single feature. Its page presents an open-source observability platform for tracing, evaluating and improving AI agents, with no framework lock-in and support for any language or stack that emits OpenTelemetry data. That architecture matters for privacy: you can choose where traces live and what gets sent.

What the product page supports

  • Self-hosting and open source. The page describes Langfuse as an "open platform, open source." For teams with strict data-residency or internal-network requirements, self-hosting keeps production traces inside your own infrastructure.
  • Data minimisation by design. Tracing captures LLM calls, tool invocations and retrieval steps, and lets you filter by user, session, cost, latency or custom metadata. You decide which fields enter a trace, so sensitive payloads can be redacted or omitted before ingestion.
  • Access control for human review. Human annotation and collaborative review workflows imply role-based access to traces and datasets. Restrict who can read production traces, especially when they contain user conversations.
  • Prompt and dataset governance. Prompt management with one-click deployments and rollbacks keeps prompts versioned and auditable; golden datasets built from reviewed traces should be scrubbed of personal data before reuse.

Practical decision criteria

Requirement What to check
Data must stay in your cloud Confirm self-hosted deployment options and network isolation
PII in prompts or outputs Verify redaction hooks and metadata filtering before ingestion
Regulated workloads Check retention controls, audit logs and access roles
Third-party model calls Confirm what trace payloads leave your environment

A concrete scenario

A fintech team instruments its support agent with OpenTelemetry and sends traces to a self-hosted Langfuse instance. They strip account numbers at the instrumentation layer, tag traces with a hashed user ID instead of an email, and give only two engineers annotation access. The trade-off is operational overhead: self-hosting means you own upgrades, storage and backups, while a managed option shifts that burden but requires reviewing the vendor's data-processing terms.

Next step

Map your trace payloads field by field, mark which are personal or regulated, and decide self-hosted versus managed before you instrument production. For deployment and security specifics, start with the official documentation at Langfuse.

Related questions

More questions →
What Are Open-Source UI Element Libraries and How Do They Differ From UI Frameworks?

An open-source UI element library is a collection of individual, ready-made interface pieces—buttons, cards, inputs, toggles, loaders—that you copy into your own project and adapt. A UI framework, by contrast, is a structured system of components, conventions, and often a theming layer that governs how your whole interface is built. The practical difference: an element library gives you a snippet; a framework gives you a way of working. If you need a polished button in ten minutes, reach for the element library. If you're building a 40-screen product with a team, you probably want the framework.

What "open-source UI element library" actually means

The term gets used loosely, so it helps to separate the parts:

  • Open-source: the code is publicly available, and the license tells you what you may do with it—copy, modify, redistribute, or use commercially.
  • UI element: a single, self-contained piece of interface, usually small enough to read in one sitting. A button with hover states, a pricing card, a search field.
  • Library: a browsable, searchable collection of those elements, typically contributed by many different people.

On a site like Uiverse, elements are shared by a community and written in plain CSS or Tailwind. You find one you like, copy the markup and styles, paste them into your project, and adjust colors, spacing, and text to fit. There's no package to install and no build step required—which is exactly the appeal, and also the source of most of the confusion.

Element library vs. UI framework: the core differences

Dimension Open-source UI element library UI framework / design system
Unit of reuse A single snippet you copy A component you import or call
Installation None; paste into your code Package install, config, sometimes a provider
Consistency Depends on you; each element may look different Enforced by shared tokens and APIs
Theming Manual edits per element Central theme/config file
Updates You own the copy; no upstream updates Version bumps bring fixes and changes
Accessibility Varies per contributor; must be checked Usually tested and documented
Best for Prototypes, landing pages, small sites, one-off needs Multi-page apps, teams, long-lived products
Learning curve Low—read the CSS Higher—learn the API and conventions

The table isn't a verdict. It's a map of trade-offs. Element libraries win on speed and freedom; frameworks win on consistency and maintenance.

Licensing and attribution: what to check before you paste

This is where people get into trouble, and it's worth slowing down for.

  1. Find the license. Every element or collection should state one. Common open-source licenses include MIT, Apache-2.0, and BSD. Some projects use copyleft licenses like GPL, which can impose obligations if you redistribute your code.
  2. Understand what the license permits. MIT and Apache-2.0 are permissive: you can typically use the code in commercial and closed-source projects. Copyleft licenses may require you to release derivative source under the same terms.
  3. Check attribution requirements. Permissive licenses usually require you to keep the copyright notice and license text somewhere in your project. That's a real obligation, not a formality.
  4. Look for per-element terms. On community sites, the site's overall terms and the individual contributor's stated wishes may differ. If a contributor asks for credit, honor it.
  5. When in doubt, ask or avoid. If a snippet has no license at all, you don't have clear permission to reuse it. Treat "no license" as "not open source," even if the code is publicly visible.

This article is general information, not legal advice. For commercial products with real exposure, have someone qualified review the licenses you're relying on.

How to use a community element in your project: a practical workflow

Here's a repeatable process that avoids most of the usual mess.

1. Start from a real need, not a browsing session

Decide what you need first—"a compact primary button with a loading state"—then search. Browsing aimlessly produces a pile of pretty snippets that don't fit together.

2. Copy the smallest version that works

Take the markup and the styles. Strip anything you don't need: demo wrappers, extra animations, decorative layers. Less code means fewer surprises.

3. Convert it to your conventions

If your project uses design tokens or CSS variables, replace hard-coded values:

/* Before: hard-coded */
.button { background: #4f46e5; border-radius: 8px; }

/* After: token-based */
.button { background: var(--color-primary); border-radius: var(--radius-md); }

This one step is what keeps a copied element from looking like a foreign object in your UI.

4. Check accessibility before you ship

Community elements vary widely here. Verify at minimum:

  • Keyboard focus is visible and the element is reachable by Tab.
  • Color contrast meets WCAG AA (4.5:1 for normal text).
  • Interactive elements use semantic HTML (<button>, not a clickable <div>).
  • Form inputs have associated labels.
  • Motion respects prefers-reduced-motion.

5. Test in context

Paste it into a real page with real content. Long labels, small screens, and dark mode break more copied elements than anything else.

6. Note where it came from

Keep a short comment or an internal credits file: source, license, date. Future you—and your legal reviewer—will be grateful.

Where element libraries genuinely shine

  • Prototypes and demos: you need something clickable today, not a design system.
  • Landing pages and marketing sites: a handful of distinctive elements, each custom.
  • Filling gaps: your framework lacks one specific component, and you don't want to build it from scratch.
  • Learning: reading well-made CSS is one of the fastest ways to improve.
  • Small projects: a personal site doesn't need a theming architecture.

Where they fall short

  • Consistency at scale: ten elements from ten contributors rarely look like one product.
  • Maintenance: you own every copy. When your design changes, you edit each one.
  • Accessibility debt: you inherit whatever the contributor did or didn't do.
  • No upstream fixes: a bug fixed in the original won't reach your copy.
  • Integration friction: different naming conventions, different units, different assumptions about resets.

When to choose which

Choose an element library when the scope is small, the timeline is short, or you need a few distinctive pieces rather than a whole system.

Choose a framework or design system when multiple people build multiple screens over months, when consistency is a product requirement, or when accessibility and theming need to be guaranteed rather than checked.

A hybrid works well for many teams: adopt a framework for the structural components—forms, navigation, layout—and borrow individual elements for the places where you want personality. Just route every borrowed element through the same token and accessibility checks, so it lands as part of your system rather than beside it.

The short version: open-source UI element libraries are a fast, flexible way to get good-looking interface pieces into a project. They are not a substitute for a design system, and the license and accessibility details are the part worth reading carefully.

What Can You Actually Do With a Free Hosted REST API Like ReqRes?

A free hosted REST API like ReqRes gives you a real HTTP endpoint you can call immediately—no signup, no local server, no database setup. You get predictable JSON responses for users, resources, login, and registration, which makes it useful for front-end demos, integration tests, learning HTTP clients, and prototyping. What it is not is a production backend for your app: the data is shared, resets periodically, and you don't control the schema. If you need persistent, private data with auth and logs, that's where an account-based backend or a commercial licence comes in.

What "free REST API for testing and prototyping" actually means

The phrase sounds vague, so it helps to separate two things people often conflate:

  • A mock/sample API — a public, hosted service with fixed or semi-fixed endpoints that return realistic-looking JSON. You don't own the data. It exists so you can point code at a URL and get a response.
  • A real backend you configure — a service where you define collections, schemas, authentication, and logging, and where your data persists and belongs to you.

ReqRes's landing page describes both: a free REST API for testing and prototyping with real responses and no signup, plus an option to build your own backend with collections, auth, and logs at app.reqres.in. Those are different products with different trade-offs. The free public endpoints are the "point and go" part; the account-based backend is the "own your data" part.

What you can do with the no-signup public endpoints

1. Front-end demos without a backend

If you're building a UI and need data to render, you can fetch from a public endpoint instead of hardcoding arrays. This keeps your demo code closer to real fetch logic:

async function loadUsers(page = 1) {
  const res = await fetch(`https://reqres.in/api/users?page=${page}`);
  if (!res.ok) throw new Error(`HTTP ${res.status}`);
  const { data, total, page: current } = await res.json();
  return { users: data, total, page: current };
}

You get pagination fields, a data array, and support metadata—enough to build list views, loading states, and empty states.

2. Integration and contract tests

You can assert that your HTTP layer handles status codes, headers, and JSON shapes correctly. Typical checks:

  • GET /api/users/2 returns 200 with a data object.
  • GET /api/users/23 returns 404 (a non-existent user).
  • POST /api/login with valid credentials returns a token; with missing fields returns 400.

This is useful for testing your client wrapper, retry logic, error handling, and serialization—without spinning up your own server.

3. Learning HTTP clients and tooling

If you're new to fetch, Axios, curl, Postman, or HTTPie, a hosted API is a low-friction target. You can practice:

  • Sending query parameters (?page=2, ?delay=3).
  • Setting headers and reading response headers.
  • Handling POST, PUT, PATCH, DELETE.
  • Observing status codes for success and failure.

4. Deliberate failure and latency testing

Endpoints that return 404 on purpose, or that accept a delay parameter, let you test how your app behaves when things go wrong or slow down. That's hard to do reliably against a happy-path local mock.

What the public endpoints are not good for

Use case Public sample endpoints Account-based backend
Persistent, private data No — shared and reset Yes
Custom schema/collections No Yes
Authentication you control Limited (demo login) Yes
Request logs and debugging No Yes
Production traffic Not intended Depends on plan/licence
Team collaboration No Yes

The key limitation: you don't own the data, and other people are hitting the same endpoints. Treat responses as illustrative, not authoritative.

When you'd move to an account-based backend

Consider app.reqres.in (collections, auth, logs) when any of these are true:

  • You need your own collections and fields, not the fixed demo schema.
  • You need data to persist between sessions and belong only to you.
  • You need real authentication flows you can rely on in a demo or internal tool.
  • You need request logs to debug what your client actually sent.
  • You're working with a team and need shared, stable endpoints.

The trade-off is setup and, eventually, cost. The public endpoints require none; the backend requires an account and configuration.

Where pricing and licensing become relevant

The site signals a commercial licence and an upgrade path (with Stripe as the payment platform), but specific prices, plan tiers, and limits aren't stated here—so don't assume numbers. What you can reason about:

  • Prototyping and learning → free public endpoints are usually enough.
  • Internal tools, demos for clients, or anything you don't want reset → an account-based backend is the natural next step.
  • Production or commercial use → check the licence terms and any paid plan, because "free for testing" and "free for commercial production" are not the same thing.

Before committing, read the current terms on the site rather than relying on secondhand summaries, since pricing and licence scope change.

A quick decision checklist

  1. Do you need data that persists and is private? If yes → account-based backend.
  2. Do you need a custom schema? If yes → account-based backend.
  3. Are you only testing HTTP behavior, UI rendering, or learning a client? If yes → free public endpoints.
  4. Will this touch real users or revenue? If yes → review the licence and any paid plan first.
  5. Do you need logs and team access? If yes → account-based backend.

If you answer "no" to 1, 2, 4, and 5, the free hosted API is likely all you need. If you answer "yes" to any of them, plan for the account-based path.

Website Overview

The available information shows a mix of normal operation and configuration gaps. Depending on how the website is used, these gaps may affect secure access or the consistency of its public presentation.

Domain and Registration

Transfer-protection status is present, helping reduce the risk of unauthorized domain transfers. The domain has about 3 years of registration history; its current configuration provides more context than age alone. The registrar is Cloudflare, Inc., a widely used domain service provider. The domain uses the common .com extension, which is not an independent safety signal.

DNS and Email

Nameservers are provided by Cloudflare, indicating managed DNS hosting. MX records point to the Google Workspace email service. DNSSEC is enabled, allowing validating resolvers to authenticate signed DNS data. No CNAME was found; the observed records resolve directly to addresses. SPF and DMARC are configured. DKIM status is unknown.

TLS and Certificates

The certificate uses an RSA 2048-bit public key, offering broad client compatibility. The server supplied a complete certificate chain. No organization name is present in the certificate; the available fields are consistent with domain validation. The certificate was issued by Let's Encrypt, commonly associated with automated certificate services. The certificate's total validity is about 89 days, consistent with a short renewal cycle.

HTTP and Browser Security

X-Powered-By exposes backend information: Next.js. All six checked browser-security headers are present. Their effectiveness still depends on the policy values and application behavior. No obvious internal addresses or debug information were found in the headers. The Server header contains the custom value Vercel. No explicit CDN or WAF marker was found in the response headers.

Technology Stack Analysis

The public page identifies Next.js, Google Tag Manager, Google Analytics, Vercel without precise versions, leaving fewer clues for version-specific scanning.

Search and Social Sharing

The meta description has 179 characters and may be shortened in search results. Twitter Card metadata is configured. The title has 49 characters, within a common display range. The observed directives allow indexing and link following. No Generator meta tag is publicly exposed.

Hosting and Email

DNSCloudflare
HostingVercel
EmailGoogle Workspace
Location United States flagUnited States 216.150.1.1

User reviews (0)

  • No reviews yet.

Pages, Search and Sharing

Meta descriptionTrace, evaluate, and improve AI agents with one open platform. Use production data to understand behavior, collaborate on fixes, and ship better quality at lower cost and latency.
Canonical URLhttps://langfuse.com
LanguageEnglish (default)
Twitter Cardsummary_large_image
All bots 1 allowed · 0 disallowed
  • Allow/

Registration details RDAP / WHOIS

RegistrarCloudflare, Inc.
Registered2023-04-20
Expires2027-04-20
Domain statusclient transfer prohibited
Nameserverschad.ns.cloudflare.com、elisabeth.ns.cloudflare.com
DNSSECsigned

DNS records

TypeNameValueTTLPriority
Alangfuse.com216.150.1.1300—
MXlangfuse.comaspmx.l.google.com3001
MXlangfuse.comalt1.aspmx.l.google.com3005
MXlangfuse.comalt2.aspmx.l.google.com3005
MXlangfuse.comalt3.aspmx.l.google.com30010
MXlangfuse.comalt4.aspmx.l.google.com30010
NSlangfuse.comchad.ns.cloudflare.com86400—
NSlangfuse.comelisabeth.ns.cloudflare.com86400—
TXTlangfuse.comMS=ms48392532300—
TXTlangfuse.comgoogle-site-verification=VExrjDnlR8fceiTh5-dNaoZVDOZxObVC-s_984Fc2AE300—
TXTlangfuse.comgoogle-site-verification=xzRwcd14JOyCZ7X_yd8ZjS_WF_mcForWbhs0G4-E61Q300—
TXTlangfuse.comhubspot-developer-verification=MDhlYTM4M2QtMDgwYy00MzU5LTliODEtNTI2ZGEwOTNiZDIy300—
TXTlangfuse.comslack-domain-verification=VaXU8x9u8aQHVP4CKICN8D6DNlpSQIs3jiODAGAe300—
TXTlangfuse.comv=spf1 include:_spf.google.com -all300—
DSlangfuse.com2371 13 2 304867faba6551f85e0309c4fb28dd600fbf1f1c571846c6ef66996b8586743186400—
DMARC_dmarc.langfuse.comv=DMARC1; p=reject; pct=100; rua=mailto:[email protected]; sp=reject; aspf=r;300—

TLS and certificates

AssessmentNormal configuration
Supported protocolsTLSv1.2、TLSv1.3
Negotiated protocolTLSv1.3
Certificate subjectlangfuse.com
IssuerLet's Encrypt
Valid until2026-12-16T03:18 · Remaining when checked: 82 days
Verification detailsCertificate trust: Passed · Hostname match: Passed

HTTP response headers

HeaderValue
content-typetext/html; charset=utf-8
cache-controlpublic, max-age=0, must-revalidate
serverVercel
strict-transport-securitymax-age=63072000
content-security-policydefault-src 'self' https: wss:; script-src 'self' 'unsafe-eval' 'unsafe-inline' https:; style-src 'self' 'unsafe-inline' https:; img-src 'self' https: blob: data:; media-src 'self' https: blob: data:; font-src 'self' https:; frame-src 'self' https:; worker-src 'self' blob:; object-src 'none'; base-uri 'self'; form-action 'self'; frame-ancestors 'none'; upgrade-insecure-requests; block-all-mixed-content;
x-frame-optionsSAMEORIGIN
x-content-type-optionsnosniff
referrer-policystrict-origin-when-cross-origin
permissions-policyautoplay=*, fullscreen=*, microphone=*

Identified technologies

Next.jsGoogle Tag ManagerGoogle AnalyticsVercel