Angular Agency SSL Monitoring: Firebase, Azure Static Web Apps, and AWS Amplify SSL Patterns

Angular is a TypeScript-based web framework for building single-page applications and progressive web apps. Agencies building Angular applications for clients deploy to a range of hosting platforms — Firebase Hosting, Azure Static Web Apps, AWS Amplify Hosting, and others. Each platform manages SSL differently, and the failure modes that affect Angular deployments vary by platform in ways that are not always obvious.

This guide covers the SSL monitoring requirements specific to Angular agency deployments on the three most common platforms.

Platform Overview: Three SSL Systems for Angular Deployments

Angular agencies frequently deploy to three platforms with fundamentally different SSL provisioning approaches:

Firebase Hosting uses Google-managed SSL certificates. Custom domains provisioned through Firebase are backed by Google's Certificate Authority infrastructure, not Let's Encrypt. Certificate renewal is managed by Google automatically and is not dependent on periodic DNS validation after initial provisioning.

Azure Static Web Apps uses Azure-managed Let's Encrypt certificates. Custom domain SSL is provisioned through a Let's Encrypt integration managed by Azure. Renewal requires Azure's automated system to validate the domain each cycle.

AWS Amplify Hosting uses AWS Certificate Manager (ACM) for SSL. Each custom domain configured on an Amplify app gets an ACM certificate provisioned and managed by AWS. ACM renewal uses DNS validation — a CNAME record in the client's DNS zone must remain present for ACM to renew the certificate without human intervention.

Firebase Hosting: Google-Managed Certificates and Custom Domain Verification

Firebase Hosting provisions SSL using Google's managed certificate infrastructure. The provisioning process requires the custom domain to be verified through Firebase console:

Apex domains require either A records pointing at Firebase's IPs or a redirect configuration in the Firebase console
Subdomains require a CNAME pointing at <project-id>.web.app

The Firebase Provisioning Window

Firebase describes a provisioning window of up to 24 hours after DNS changes propagate before SSL becomes active. During this window, HTTP is served. After provisioning completes, HTTPS is enforced. If DNS propagation is incomplete during the provisioning attempt, Firebase may provision successfully for the records that did resolve — which can result in partial SSL coverage where the apex works but the www subdomain does not, or vice versa.

The Key Firebase SSL Monitoring Need

Google-managed certificates on Firebase do not require periodic DNS re-validation for renewal (unlike Let's Encrypt HTTP-01). However, the initial provisioning and any re-provisioning after a domain configuration change requires correctly configured DNS. If a client changes their domain's DNS — moving nameservers, changing registrars, or pointing the domain elsewhere — Firebase loses the ability to verify the domain and will not re-provision the certificate.

What to monitor on Firebase Hosting: DNS integrity on the CNAME or A records pointing at Firebase infrastructure. A DNS change that redirects the custom domain away from Firebase's IPs is the earliest signal of a forthcoming SSL failure. DNS change monitoring that fires on the same day as a DNS change gives agencies time to investigate before provisioning is affected.

Azure Static Web Apps: Let's Encrypt Renewal and CNAME Validation

Azure Static Web Apps uses Azure-managed Let's Encrypt certificates for custom domains. Custom domain SSL is provisioned when the custom domain is added and the DNS is validated:

Apex domains require an ALIAS or ANAME record pointing at the Static Web App's default hostname, or an APEX subdomain override
Subdomains (including www) require a CNAME pointing at the Static Web App's <name>.azurestaticapps.net hostname

Azure uses HTTP-01 or DNS-01 validation for Let's Encrypt certificate provisioning, depending on the domain type. Certificates are renewed at approximately 60 days into the 90-day validity period.

The Azure Static Web Apps SSL Risk

Azure's automated renewal depends on the domain's DNS pointing at Azure at the time of renewal. If a client changes their DNS — pointing the CNAME at a different host, moving nameservers to a provider that does not support CNAME at the apex — the renewal attempt fails. Unlike Azure's managed CNAME validation for ACM (which persists until the CNAME is removed), Let's Encrypt HTTP-01 validation requires the domain to actively resolve to Azure's infrastructure at renewal time.

Additionally, Angular applications deployed as Azure Static Web Apps frequently have an API backend using Azure Functions proxied through the same Static Web App. The API routes (/api/) share the same SSL certificate as the frontend. If the Static Web App SSL is interrupted during a domain reconfiguration, the API calls fail too — which in an Angular SPA manifests as silent data loading failures rather than a browser SSL error, making the SSL expiry harder for clients to notice.

What to monitor on Azure Static Web Apps: CNAME integrity on each custom domain, and SSL expiry with a 30-day alert. SSL certificate monitoring with a 30-day threshold aligns with Azure's renewal window — if renewal fails at 60 days, the 30-day alert fires before expiry.

AWS Amplify Hosting: ACM and the DNS Validation CNAME

AWS Amplify Hosting provisions SSL using AWS Certificate Manager (ACM). Each custom domain on an Amplify app gets one or more ACM certificates — typically one per subdomain or subdomain group configured on the app.

ACM certificates use DNS validation: AWS generates a CNAME record that must be added to the custom domain's DNS zone. This CNAME must remain present in the DNS zone for as long as the certificate needs to be renewed. ACM renewal is automatic as long as the validation CNAME is present.

The Amplify ACM DNS Validation Failure Mode

The ACM validation CNAME is a record the agency adds during setup and then never touches again. It has no visible effect on the site's operation — it is purely a validation record. In practice, this means clients and their IT teams often delete it during DNS migrations, zone cleanups, or "unnecessary records" removal exercises.

When the ACM validation CNAME is deleted, ACM can no longer renew the certificate automatically. The existing certificate continues serving until it expires. ACM sends email notifications to the AWS account owner when renewal is at risk — but if the Amplify app is under the client's AWS account (or if the agency is not monitoring the AWS account's email), those notifications are not seen.

Angular SPAs on Amplify often have multiple subdomains configured: the main app domain, a staging or preview URL on a subdomain, and occasionally a separate API subdomain. Each subdomain configuration generates its own ACM certificate, with its own validation CNAME. All of them need to remain present in the DNS zone.

What to monitor on AWS Amplify: The presence of each ACM validation CNAME in the client's DNS zone, and SSL expiry with a 30-day alert on every subdomain. A DNS zone cleanup that removes the validation CNAME is detected immediately rather than when ACM reports a renewal failure 60+ days later.

The Angular SPA SSL Failure Mode Agencies Miss

Angular SPAs have a specific SSL failure characteristic that makes certificate expiry harder to detect than on traditional server-rendered applications.

When an Angular SPA is served with an expired SSL certificate, modern browsers block the initial HTML document load with an SSL error — the user sees the browser's "Your connection is not private" page. This is visible.

However, when the Angular SPA's API backend has an expired SSL certificate and the SPA frontend SSL is still valid, the Angular app loads and renders normally. The app then makes API calls to the backend. If the backend API SSL has expired, the browser blocks those API requests — but Angular typically handles these as network errors, not fatal application errors. The result is an Angular app that displays the loading state indefinitely, or that renders with empty data, or that shows an application-level error message. The client may not immediately recognize this as an SSL problem.

Monitoring implication: Angular agencies need to monitor SSL on both the SPA frontend domain and any API backend subdomains — separately, with independent expiry alerts. Monitoring API subdomains as independent assets with their own SSL checks ensures the backend expiry is caught before clients report silent data failures in the Angular app.

Monitoring Setup for Angular Deployments in Merlonix

For each Angular client deployment:

Firebase Hosting:

Add the apex domain and www subdomain as separate assets
DNS change monitoring on A records and CNAME pointing at Firebase infrastructure
SSL expiry monitoring with 30-day alert on each custom domain

Azure Static Web Apps:

Add the Static Web App's custom domain as an asset
CNAME integrity check on the custom domain pointing at <name>.azurestaticapps.net
SSL expiry monitoring with 30-day alert

AWS Amplify:

Add every custom domain and subdomain as separate assets
DNS monitoring to detect removal of ACM validation CNAMEs
SSL expiry monitoring on every subdomain with 30-day alert

In all three cases: add the hosting platform (Firebase, Azure, or AWS) as a vendor status feed to separate platform-level incidents from individual client DNS problems.

Merlonix is built for agency portfolio monitoring — SSL expiry alerts, DNS change detection, vendor status tracking, and per-client alert routing across Firebase, Azure, and AWS deployments. Start a free trial and add your first Angular client domain.