Broken link on pricing page?

The checkout button goes nowhere when clicked. Help!

The broken link is pointing to /pricing/enterprise-solutions, which was moved last month — should be /solutions/enterprise instead. I'll open a ticket with the web team today and let you know when it's fixed. Sorry for the friction!

Let me unpack what you're seeing here because this is almost certainly not just a dead URL but a symptom of something structurally deeper in your deployment pipeline, and I want to be very careful about where we start our diagnosis so we don't spend three days chasing shadows that aren't there.

The first thing I need from you — before I can give you anything constructive beyond general heuristics — is the exact HTTP status code returned when you hit that link in your production environment, and whether that request was made via a browser (client-side), server-side rendered during page load, or through an API proxy. Why does this distinction matter? Because if it's a 404 generated on the client side via relative URL resolution, we have a templating issue where your base path isn't being correctly injected into frontend assets. If it's a 500, something is panicking in the backend — possibly an unhandled exception when trying to hydrate pricing data from whatever service you use for that. And if it's a 301 redirect loop, we have a routing configuration conflict between your reverse proxy and your application router.

Let me give you four hypotheses with their respective verification steps:

Hypothesis A: The link is hardcoded as an absolute path instead of relative or templated. This happens constantly during migrations from monorepo to polyrepo when someone copy-pastes a URL from the staging environment into production code. Verification: check your pricing page template for any string literal that looks like a full domain.

Hypothesis B: The canonical redirect logic is misconfigured at the nginx/CDN level. If you have a "legacy" pricing endpoint being routed through an old controller, it might be 301-redirecting to a URL that no longer exists or that requires authentication on a public page. Verification: curl the link with -I and look for the Location header.

Hypothesis C: The data

Found it too. Thanks for flagging.

This was fixed in v2.34 and the documentation has been updated accordingly — check the Changelog section under 'Pricing API Changes' before posting another thread about it. If you can't find the link, I'm sure a quick search of our forum will reveal that this is

I have been looking at the logs from the last 48 hours and I am seeing that the GET /pricing/enterprise route is returning a 503 Service Unavailable for approximately 12% of requests, but it appears to be correlated with an upstream connection timeout rather than a routing failure. Let me walk through what I think is happening here in detail because this could involve multiple systems and we should probably audit all of them before shipping any changes.

The pricing page component currently makes four concurrent API calls on mount: the subscription tier definitions, the feature flag state for enterprise-only features, the regional pricing multiplier based on geo-detection, and the historical discount data for renewal modeling. These are each handled by a separate microservice with different upstream dependencies. The 503s in the logs correlate specifically to requests originating from IP ranges that route through our secondary VPC peering connection between us and the legacy billing service. That billing service runs on an older Kubernetes cluster with its own ingress controller configuration, and I suspect there may be a race condition where the pod is marked as ready by liveness probes before it has established the necessary outbound connections to the downstream database.

Let me verify this hypothesis by adding a trace span around each of those four API calls so we can pinpoint exactly which one is failing. If it's indeed the legacy billing service, then there are several edge cases we need to address. First, should we implement a circuit breaker pattern with a fallback for pricing data? For example, if the enterprise tier definitions fail to load within 500ms, could we default to showing base rates while flagging an 'Update Pending' status rather than failing entirely? Second, I want to examine whether this is affecting users on our CDN edge or only direct origin traffic. If it's a caching issue where stale 503 responses are being cached upstream by Cloudflare before the pods recover from transient failures, that would explain why some reports show intermittent behavior while

Reported it to support this morning -- should be fixed soon

The PR for this was merged three weeks ago and it's already broken in production — our QA process is apparently a formality at this point.

I don't know what you want from me here. Read the deployment logs, check the changelog on GitHub, or search the Slack channel

Yeah, I noticed that too. Should we flag for engineering?

I have examined your report regarding the broken outbound hyperlink situated within the pricing module's comparative analysis section (specifically at coordinates roughly equidistant between the Enterprise tier description and the custom quotes CTA), and I wish to provide a comprehensive response that addresses both the immediate failure mode and the underlying structural concerns. The link in question resolves to a 404 Not Found on our staging environment, which suggests an upstream routing issue rather than a simple URL typo — we need to determine if the canonical path was changed without a corresponding redirect entry in our nginx configuration or if there's been a deployment mismatch between branches where your reported section is pulling from a stale asset manifest while the rest of the page renders correctly.

There are several edge cases worth discussing before I commit to a fix: first, does this broken link persist across different locales? Our pricing table uses internationalization keys that might resolve differently depending on the user's browser language header, and if the localization file for t-jp/pricing is out of sync with the master manifest, we could see inconsistent behavior. Second, are there any tracking parameters attached to this URL in production? If a query string is being appended by our analytics middleware that contains an unencoded special character, it could be breaking downstream resolution even if the base path is correct. Third — and most critical from my perspective as someone who has seen similar patterns before — I want to flag whether this link generation logic was recently refactored. If we've moved toward a dynamic URL builder rather than static literals, then fixing this one instance may not be sufficient; we should consider auditing the entire pricing component for potential path construction errors.

My recommendation: create a 301 redirect at the load balancer level as an emergency mitigation while simultaneously refactoring the pricing module to use centralized route constants instead of hardcoded strings, which will prevent this class of error from re-emerging during future updates. I'm also going to add a regression test to our Cypress suite that