One NestJS product is REST gateway, gRPC services, GraphQL Federation, and WebSocket endpoints.
Each subdomain has its own SSL termination. Most fail silently.
NestJS agencies running microservice architectures deal with cert-manager renewal failures on Kubernetes when a stuck Order resource blocks ACME issuance across every service in the cluster, AWS ALB cert mis-attachment when adding a new microservice subdomain without attaching its ACM cert to the listener, and Google Cloud Run custom-domain mappings that silently break during region migrations. Merlonix monitors SSL and DNS so you catch certificate failures before clients see handshake errors on their gRPC clients or WebSocket connections.
No credit card for the trial. Cancel any time.
- Check cadence (Agency)
- 5 min
- SSL pre-expiry alert
- 30 days
- Independent DNS resolvers
- 3
- Vendors watched
- 11
Where NestJS agencies get caught out
Three failure modes specific to NestJS microservice architectures across Kubernetes, ALB, and Cloud Run.
NestJS agencies running microservices across REST, gRPC, GraphQL, and WebSocket subdomains deal with cert-manager renewal failures on Kubernetes blocking ACME issuance across every service, ALB cert mis-attachment when adding new microservice subdomains, and Cloud Run domain mapping gaps during multi-region migrations where DNS is updated before SSL provisioning completes.
Kubernetes cert-manager renews via ACME but a stuck Order resource (rate-limited by Let's Encrypt, blocked by a misconfigured ClusterIssuer, or held by a Challenge waiting on DNS-01 propagation) blocks renewal across every NestJS microservice using that issuer until manually unstuck
A NestJS microservice cluster on EKS uses cert-manager with a single ClusterIssuer pointing at Let's Encrypt. Six microservices — gateway, auth, billing, notifications, search, analytics — each have their own Certificate resource referencing the issuer. When one Order gets stuck because the underlying Challenge cannot complete DNS-01 validation due to a Route53 IAM permission change, cert-manager retries with exponential backoff. Other microservices renewing through the same issuer queue behind the stuck Order
The agency's cert-manager Helm chart was deployed nine months ago using an IAM role for the dns01 solver that was scoped to specific Route53 hosted zones. A platform engineer updates Route53 hosted zone IDs as part of a domain consolidation, but the cert-manager IAM policy still references the old zone ARNs. Three microservices need renewal in the same week. The first hits the IAM permission failure, gets stuck in a retry loop, and never completes. The next two queue behind it. cert-manager logs show the failure but the Kubernetes events have already rotated out of the cluster's default retention window. The agency learns about the failure when Datadog reports a spike in 5xx errors from the gateway service — except it's not a 5xx, it's a TLS handshake failure that internal monitoring is misclassifying. Two microservices have already expired by the time the engineer is paged. The remaining three are within 14 days of their renewal window.
AWS ALB-fronted NestJS services require ACM certificates attached per-listener — when a new microservice subdomain is added to an ALB target group without also attaching its ACM cert to the HTTPS listener, the ALB serves its default certificate which does not match the custom domain
A NestJS agency adds a new microservice — events.client.com — to an existing ALB-fronted gRPC architecture. The agency creates the target group, registers the ECS service with the new task definition, and creates a Route53 alias record pointing events.client.com at the ALB. The ALB has an HTTPS listener with multiple ACM certificates attached for the existing microservices but the new events.* cert is not added to the listener. Requests to events.client.com hit the ALB, get matched to the target group, but the TLS handshake fails because the ALB serves the default cert
A NestJS agency uses one ALB to front five microservices behind path-based routing rules: gateway, auth, billing, notifications, and search. Each has an ACM certificate attached to the HTTPS listener via the ALB console. The agency adds a sixth microservice — events — for real-time WebSocket-based notifications. The ECS task definition deploys cleanly. The target group health check passes. Route53 is updated to alias events.client.com to the ALB DNS name. The gRPC client in the mobile app starts hitting events.client.com and immediately fails with TLS_HANDSHAKE_TIMEOUT. The agency engineer assumes the issue is in the new microservice itself and spends three hours debugging the WebSocket gateway code. The actual cause is that ACM cert for events.client.com was never attached to the ALB's HTTPS listener — the listener has five certs, not six. The agency learns this only after enabling ALB access logs and seeing the SNI hostname mismatch.
Google Cloud Run custom domain mappings depend on the Cloud Run service's region — a region migration to move closer to a client's user base requires re-issuing the domain mapping in the new region and the SSL certificate is provisioned fresh; if DNS is updated before validation completes, the new region serves over HTTP only
A NestJS agency runs a microservice on Cloud Run in us-central1 with a custom domain mapping. A client requests an EU presence for compliance, so the agency creates a parallel Cloud Run service in europe-west1 and updates the custom domain mapping. Cloud Run's automatic SSL provisioning requires DNS to be updated to point at the new region's ghs.googlehosted.com endpoint, then takes up to 24 hours to provision a managed certificate after DNS propagation completes
A NestJS API deployed on Cloud Run in us-central1 uses Google's Cloud Run domain mapping with the agency's custom domain api.client.com. The agency deploys a parallel service in europe-west1 to reduce latency for European users and configures a domain mapping for api-eu.client.com. The agency engineer updates DNS to point api-eu.client.com at ghs.googlehosted.com immediately after the mapping is created. The Cloud Run console shows the mapping as "Pending certificate provisioning" but the agency does not wait — they deploy the European mobile app build pointing at api-eu.client.com and ship it. For the next 18 hours, every European user's app shows a network error on launch because the api-eu subdomain serves over HTTP only. The certificate provisions overnight on the second day, but by then the App Store reviews have already accumulated complaints.
How it works
SSL and DNS monitoring for NestJS agencies across Kubernetes cert-manager, ALB ACM, and Cloud Run microservice deployments.
Merlonix monitors SSL expiry and DNS A record integrity across every NestJS microservice subdomain — REST gateways, gRPC services, GraphQL Federation supergraphs, and WebSocket endpoints — and catches renewal failures caused by stuck cert-manager Orders, ALB cert mis-attachment, or unfinished Cloud Run domain mapping validations before the certificate expires and the gRPC client returns handshake errors.
01
Add NestJS microservice subdomains — gateway, gRPC services, GraphQL Federation supergraphs, and WebSocket endpoints — with DNS TXT record verification
Verify ownership with a DNS TXT record on the apex domain. All subdomains under that apex — api.*, gateway.*, graphql.*, ws.*, events.*, and any per-microservice subdomain — are added without additional verification. Monitoring every NestJS subdomain from a single apex registration ensures that microservice subdomains added during architecture splits are covered alongside the primary gateway domain. Under two minutes per client.
02
A record and CNAME integrity monitoring across ALB DNS aliases, Cloud Run ghs.googlehosted.com mappings, and Kubernetes ingress controller endpoints
Three independent DNS resolvers check every A record and CNAME delegation on every monitoring interval. When a NestJS service moves from us-central1 to europe-west1, the new Cloud Run mapping endpoint is validated across all monitored subdomains. When a Kubernetes ingress controller is replaced and ingress IP changes, every microservice subdomain alias is re-validated. DNS change monitoring provides the audit trail confirming a region migration completed correctly across every NestJS microservice subdomain.
03
SSL monitoring 30 days before expiry across cert-manager-issued certificates, ACM certificates on ALB listeners, and Cloud Run managed certificates
Full SSL chain validation on every NestJS microservice subdomain — REST gateways, gRPC services, GraphQL endpoints, and WebSocket gateways. An expiry alert fires 30 days before the certificate expires — enough lead time to identify whether the failure is a stuck cert-manager Order, an ACM certificate not attached to the ALB listener, or a Cloud Run custom-domain mapping that never completed validation. Catches cert-manager failures before the certificate expires and the gRPC client mobile app starts returning TLS_HANDSHAKE_TIMEOUT.
04
Vendor status for NestJS hosting providers to distinguish infrastructure incidents from microservice SSL and DNS configuration failures
Merlonix monitors AWS, Google Cloud, and the major Kubernetes managed services alongside client SSL and DNS. When an EKS control plane incident causes cert-manager API failures across multiple NestJS client deployments simultaneously, you see the vendor event — not a cluster of individual SSL alerts that each require separate investigation to determine whether the root cause is an EKS outage or a stuck Order requiring manual cert-manager intervention.
What the numbers mean for NestJS agencies
Monitoring built for NestJS agencies where one client product means six microservices, each with an independent SSL termination layer that can fail silently after a Helm upgrade or an ALB listener change.
NestJS agencies managing cert-manager across Kubernetes microservice clusters, ACM across ALB listener attachments, and Cloud Run managed certificates across multi-region deployments need monitoring that covers every microservice subdomain — because a stuck cert-manager Order is silent in Kubernetes events until the certificate expires and the gateway service starts returning TLS handshake errors to mobile clients.
< 10 min
Time from DNS change to alert — catches Kubernetes ingress IP changes, ALB DNS aliases swapped during multi-region migrations, and Cloud Run ghs.googlehosted.com mapping changes before microservice clients see TLS errors
30 days
SSL expiry warning lead time — enough time to identify whether the failure is a stuck cert-manager Order, an ACM cert not attached to the ALB listener, or a Cloud Run domain mapping awaiting validation, and correct it before the cert expires
11 vendors
Upstream services monitored — AWS, Google Cloud, Cloudflare, and major managed Kubernetes platforms included to distinguish provider outages from NestJS microservice SSL and DNS failures requiring cert-manager or ALB configuration changes
200 assets
Maximum monitored domains on the Agency plan — covers REST gateways, gRPC services, GraphQL Federation supergraphs, WebSocket endpoints, and observability subdomains across a full NestJS client microservice portfolio
Pricing
Flat monthly fee. Every NestJS microservice subdomain included.
No per-microservice charges. No per-region fees. Pick the tier that fits your NestJS client and microservice count and monitor every gateway, gRPC service, GraphQL endpoint, and WebSocket subdomain without billing surprises.
Starter
For individual NestJS developers managing a small client portfolio with a few microservices each.
$29/ month
- 10 monitored assets
- 1 seat
- 15-min check cadence
- SSL + DNS + vendor monitoring
- Email + Slack alerts
Team
For NestJS agencies managing multi-service architectures across Kubernetes, ALB, and Cloud Run.
$79/ month
- 50 monitored assets
- 5 seats
- 10-min check cadence
- SSL + DNS + vendor monitoring
- Email + Slack alerts
Agency
For agencies with a full NestJS client roster across microservice deployments and multi-region setups.
$199/ month
- 200 monitored assets
- 15 seats
- 5-min check cadence
- SSL + DNS + vendor monitoring
- Email + Slack alerts
Know when a NestJS microservice subdomain or cert-manager certificate is about to expire.
Add your first NestJS client domain in under two minutes. REST gateways, gRPC services, GraphQL endpoints, and WebSocket subdomains are monitored from the same dashboard. 14-day trial, no card required.