Flutter web passing QA does not mean iOS and Android will accept the same backend cert.
Dart's native HttpClient is strict where browser networking is lenient.
Flutter agencies shipping iOS, Android, and web targets deal with Flutter web passing QA on certs that production mobile builds reject under strict Dart HttpClient validation, package:dio badCertificateCallback shims added during development that leak to production and silently mask real cert breakage, and FCM topic subscription updates failing partially when Firebase Hosting custom-domain SSL breaks. Merlonix monitors SSL and DNS so production iOS and Android users don't hit a cert error that Flutter web QA never saw.
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 Flutter agencies get caught out
Three failure modes specific to Flutter deployments across Flutter web, iOS, and Android targets, with package:dio HTTP clients and FCM topic-based push subscriptions.
Flutter agencies deal with Flutter web passing QA on certs that production iOS and Android builds reject under strict Dart HttpClient validation (Chrome auto-fetches missing intermediates; Dart does not), package:dio badCertificateCallback debug shims leaking to production (cert expires silently and the app keeps working with a stale chain), and FCM topic-based push subscription updates failing partially when Firebase Hosting custom-domain SSL breaks (individual-token pushes still work — confusing partial failure that takes weeks to diagnose).
Flutter web uses browser networking with lenient cert handling (the same forgiving SSL stack that Chrome and Safari use), while Flutter iOS and Android use Dart's native HttpClient with strict cert chain validation. Agency QA passing on the Flutter web target does not guarantee production iOS and Android builds will accept the same backend cert — incomplete chains, missing intermediates, and SAN list mismatches all surface only on the mobile targets
A Flutter agency builds a client product targeting iOS, Android, and web from a single codebase. The QA team validates each release against the Flutter web build deployed to a staging URL — sign-in works, API calls succeed, push registration completes. The release ships to App Store and Play Store. Production iOS and Android users immediately hit "Connection error" because the backend cert at api.client.com is missing an intermediate cert in the chain — Flutter web in Chrome accepted it because Chrome auto-fetches missing intermediates; Dart's HttpClient on iOS and Android does not
A Flutter agency operates a client B2C app with iOS, Android, and Flutter web targets all built from a single Dart codebase. The agency's QA process tests each release against the Flutter web build deployed to staging.client.com. The backend at api.client.com is hosted behind nginx with a Certbot cert that's missing the intermediate cert in the chain (the agency engineer ran `certbot certonly --webroot` and forgot to symlink fullchain.pem into the nginx config — only cert.pem is referenced). Flutter web QA passes — Chrome silently auto-fetches the missing intermediate via AIA chasing and validates the chain. The release ships to the App Store and Play Store. Production iOS and Android users immediately get "Connection error" on sign-in. The Flutter app uses Dart's native HttpClient (no AIA chasing in the default Dart HTTP stack); the chain validation fails. The agency engineer can't reproduce the issue on Flutter web at all and spends three hours debugging Dart networking code before testing api.client.com directly with `openssl s_client -connect api.client.com:443 -showcerts` and seeing the chain is incomplete.
package:dio is the most popular HTTP client in the Flutter ecosystem. Its badCertificateCallback hook lets developers accept self-signed certs during development for proxying through Charles, Proxyman, or mitmproxy. When this debug-only configuration accidentally ships to production, the app accepts ANY cert — opening a MITM vector AND silently masking real cert breakage. The cert can expire and the app keeps "working" because nothing validates the chain anymore
A Flutter agency uses package:dio in their client app and configures Dio with a badCertificateCallback that returns true to allow Charles Proxy to inspect API traffic during development. The configuration is wrapped in a `kDebugMode` check, but a refactor splits the Dio client setup into a shared module and the kDebugMode wrap is lost. The shim ships to production. The app accepts every cert presented, including the expired Let's Encrypt cert that has been broken for three weeks — the agency had no idea
A Flutter agency uses package:dio for HTTP networking in a client e-commerce app. During development, an engineer configured Dio with a custom HttpClient via `dio.httpClientAdapter = IOHttpClientAdapter()..onHttpClientCreate = (client) { client.badCertificateCallback = (X509Certificate cert, String host, int port) => true; return client; }` so they could proxy traffic through Charles to debug API responses. The configuration was originally inside an `if (kDebugMode) { ... }` guard. Six months later, a refactor moves the Dio setup into a shared `lib/networking/api_client.dart` module to share between the main app and a companion widget. The kDebugMode wrap is lost in the move. The bad-cert shim ships to production. The Let's Encrypt cert at api.client.com expires three weeks later — but the Flutter app keeps working perfectly because Dio accepts the expired cert. The agency only learns about the cert breakage when a security audit runs months later and flags the production binary as accepting any cert. The window between cert breakage and discovery includes a successful but invisible MITM opportunity for any user on a malicious WiFi.
FCM topic-based push subscription updates require a valid HTTPS chain to Firebase Hosting's custom-domain layer (when the project uses a custom Cloud Functions endpoint via Firebase Hosting rewrites for token registration). When that custom-domain SSL breaks, topic subscription updates fail silently — but individual-token push messages continue to work because they go directly to FCM's endpoints. The result is a confusing partial-failure pattern where some push notifications arrive and others don't
A Flutter agency uses FCM with topic-based push subscriptions for category-based notifications (sports/news/entertainment topics). The subscription endpoint is a Cloud Function fronted by Firebase Hosting at api.client.com. The custom-domain SSL breaks after a registrar NS change. Topic subscription updates start failing silently — but individual-token push messages (sent directly to specific user device tokens) continue working. Users complain "I stopped getting sports notifications" but engineering can't reproduce because their test device still gets direct token pushes
A Flutter agency builds a client news app that uses FCM topic-based subscriptions for category notifications. The Flutter app calls a custom Cloud Function endpoint at api.client.com/v1/subscribe (routed via Firebase Hosting rewrite to `us-central1-project.cloudfunctions.net/subscribe`) to update topic subscriptions when users toggle category preferences. The Firebase Hosting custom-domain auto-managed SSL cert at api.client.com renews automatically — until a registrar NS change moves the apex away from the registrar that was authoritative for ACME challenge validation. The Firebase-managed cert silently fails to renew. Topic subscription update calls from the Flutter app start failing under Dart's strict HttpClient validation; the app catches the error and shows a generic "Couldn't update preferences" toast. Meanwhile, individual-token FCM messages (sent from the agency's backend directly to FCM via the Admin SDK) continue arriving on user devices because they bypass Firebase Hosting entirely. Users start complaining "I stopped getting sports notifications" — but the engineering team's test devices still receive push notifications when they trigger them via the Firebase console. The partial-failure pattern delays diagnosis by two weeks; the agency only catches it when a customer-success engineer notices the support ticket cluster references topic-based categories specifically.
How it works
SSL and DNS monitoring for Flutter agencies across Flutter web vs mobile cert validation divergence, package:dio badCertificateCallback debug shims, and FCM topic-based push subscription partial failures.
Merlonix monitors SSL expiry and full chain validation across every Flutter-relevant subdomain — api.*, push.*, plus Firebase Hosting custom-domain hosts that front Cloud Functions — and catches missing intermediates that Flutter web silently auto-fetches but Dart HttpClient on iOS and Android does not, Firebase Hosting custom-domain ACME failures after registrar NS changes that produce confusing FCM topic subscription partial failures, and registrar-driven CNAME changes that break auto-managed cert renewal — before App Store and Play Store users hit a cert error that Flutter web QA never saw.
01
Add Flutter backend domains — api.*, push.*, ota.*, plus the Firebase Hosting custom-domain hosts that front Cloud Functions endpoints — with DNS TXT record verification
Verify ownership with a DNS TXT record on the apex domain. All subdomains under that apex — api.*, push.*, ota.*, plus any Firebase Hosting custom-domain hosts that route to Cloud Functions endpoints — are added without additional verification. Monitoring every Flutter backend subdomain plus the Firebase Hosting custom-domain layer ensures that mobile-only failure modes (chain validation differences between Flutter web and Dart HttpClient on iOS/Android) are caught alongside Firebase Hosting-routed Cloud Function endpoints. Under two minutes per client.
02
CNAME and A record monitoring across Firebase Hosting custom-domain aliases (firebaseapp.com fronting), Cloud Functions us-central1-project.cloudfunctions.net hosts, and registrar NS changes that break Firebase ACME validation
Three independent DNS resolvers check every CNAME delegation on every monitoring interval. When a client's registrar NS records change (often during a domain transfer or a security review that resets NS to the registrar default), Firebase Hosting's ACME http-01 challenge can no longer complete and the auto-managed custom-domain cert silently fails to renew. The DNS change is logged immediately so the cert renewal failure 30 days later has a clear root cause rather than appearing as a mysterious partial-failure pattern in FCM topic subscriptions.
03
SSL monitoring 30 days before expiry across Flutter backend API certs, Firebase Hosting custom-domain certs, Cloud Function HTTPS callable endpoints, and full chain validation that catches missing intermediates Flutter web silently auto-fetches but Dart HttpClient does not
Full SSL chain validation on every Flutter-relevant subdomain — api.*, push.*, plus Firebase Hosting custom-domain hosts. The chain check explicitly validates that the intermediate cert is present in the served chain (not just expecting AIA chasing to fill the gap), which catches the "Flutter web QA passes but iOS/Android production fails" pattern before App Store and Play Store releases ship. An expiry alert fires 30 days before the certificate expires — enough lead time to identify whether the failure is a Firebase Hosting custom-domain ACME failure after a registrar NS change, an api.* cert with a missing intermediate that only mobile clients reject, or a forgotten package:dio badCertificateCallback shim hiding cert breakage in production.
04
Vendor status for Firebase / FCM, Apple Developer / APNs, Google Play Store, plus typical Flutter backend hosting providers to distinguish infrastructure incidents from Flutter-specific SSL chain validation failures
Merlonix monitors Firebase / FCM, Apple Developer / APNs, Google Play Store, AWS, Google Cloud, Render, and Fly.io status pages alongside client SSL and DNS. When a Firebase Hosting regional incident causes Cloud Function calls to fail across multiple Flutter 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 a Firebase regional outage, a registrar NS change breaking auto-managed cert renewal, or a missing intermediate cert that only Dart HttpClient on iOS and Android rejects.
What the numbers mean for Flutter agencies
Monitoring built for Flutter agencies where one client product means a Flutter web target deployed to staging, an iOS App Store release, an Android Play Store release, and a backend API on Firebase Hosting fronting Cloud Functions — each with different cert validation behavior and different failure surfaces.
Flutter agencies managing Flutter web vs mobile cert validation divergence, package:dio badCertificateCallback debug shims that leak to production, and FCM topic-based push subscription partial failures across multi-client deployments need monitoring that explicitly validates intermediate certs in the chain (rather than relying on browser AIA chasing) — because Flutter web QA passes on certs that production Dart HttpClient on iOS and Android will reject, and a forgotten badCertificateCallback shim hides expired certs in production while opening a MITM vector that no automated test catches.
< 10 min
Time from DNS change to alert — catches registrar NS changes that break Firebase Hosting auto-managed cert renewal across Flutter client deployments, plus CNAME flips on Cloud Functions custom-domain hosts that produce confusing FCM topic subscription partial failures
30 days
SSL expiry warning lead time — enough time to identify a Firebase Hosting custom-domain ACME failure after a registrar NS change, an api.* cert with a missing intermediate that Flutter web QA passed but Dart HttpClient on production iOS and Android will reject, or a forgotten package:dio badCertificateCallback shim hiding cert breakage
11 vendors
Upstream services monitored — Firebase / FCM, Apple Developer / APNs, Google Play Store, AWS, Google Cloud, Render, and Fly.io included to distinguish provider outages from Flutter-specific SSL chain validation failures
200 assets
Maximum monitored domains on the Agency plan — covers Flutter backend api.*, push.*, ota.*, and Firebase Hosting custom-domain hosts across a full Flutter client portfolio
Pricing
Flat monthly fee. Every Flutter backend subdomain and Firebase Hosting custom-domain host included.
No per-subdomain charges. No per-mobile-app fees. Pick the tier that fits your Flutter client and backend count and monitor every api.*, push.*, and Firebase Hosting custom- domain host without billing surprises.
Starter
For individual Flutter developers managing a small client portfolio across iOS, Android, and Flutter web targets.
$29/ month
- 10 monitored assets
- 1 seat
- 15-min check cadence
- SSL + DNS + vendor monitoring
- Email + Slack alerts
Team
For Flutter agencies managing multi-client mobile deployments with Firebase Hosting custom-domain Cloud Function fronting.
$79/ month
- 50 monitored assets
- 5 seats
- 10-min check cadence
- SSL + DNS + vendor monitoring
- Email + Slack alerts
Agency
For agencies with a full Flutter client roster including FCM topic-based push subscription endpoints and per-tenant Firebase Hosting subdomains.
$199/ month
- 200 monitored assets
- 15 seats
- 5-min check cadence
- SSL + DNS + vendor monitoring
- Email + Slack alerts
Know when a Flutter backend cert is missing an intermediate that Dart HttpClient will reject in production.
Add your first Flutter client domain in under two minutes. Backend api.*, push.*, and Firebase Hosting custom-domain hosts across every Flutter project for that client are monitored from the same dashboard. 14-day trial, no card required.