A cert expiry on api.clientco.com isn't a Supabase outage — it's the moment your CDN-in-front-of-functions.supabase.co pattern starts hard-blocking customer traffic while Supabase Status shows all green.
The CDN terminates TLS for the customer; functions.supabase.co stays healthy. Supabase Status reports no incident. Customer support tickets land four hours before your monitoring catches up.
Supabase Edge Functions agencies running production deployments with a CDN (Cloudflare, Fastly, AWS CloudFront) in front of <project-ref>.supabase.co/functions/v1/<fn> deal with cert expiry on the customer-facing apex (api.clientco.com) breaking the frontend while the upstream functions.supabase.co URL stays healthy and Supabase Status shows green (the agency's monitoring pointed at the Supabase status page misses the failure entirely; discovery happens via a Fortune-500 client's monitoring), JWT-authenticated function calls (the `Authorization: Bearer <token>` header verified per-request by Edge Functions) breaking inconsistently across browser TLS session resumption + HSTS-cache states when the API-gateway cert expires mid-session, and `pg_net` Database Webhook targets (Stripe, HubSpot, Slack, Twilio, customer CRMs) failing silently against expired-cert partner endpoints with failed events accumulating in net._http_response but never reaching the on-call rotation. Merlonix monitors every customer-facing apex plus the CDN-to-functions/v1/ upstream chain so cert expiry surfaces 30 days before the failure window opens.
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 Supabase Edge Functions agencies get caught out
Three failure modes specific to CDN-fronted Supabase Edge Functions where cert expiry on the customer-facing apex breaks the frontend while functions.supabase.co stays healthy and Supabase Status shows green, JWT-bearing requests break inconsistently across browser TLS-session-resumption + HSTS-cache states when the API gateway cert expires mid-session, and `pg_net` Database Webhook targets fail silently against expired-cert partner endpoints with no alerts wired.
Supabase Edge Functions agencies running production deployments with a CDN (Cloudflare, Fastly, AWS CloudFront) in front of <project-ref>.supabase.co/functions/v1/<fn> deal with cert expiry on the customer-facing apex (api.clientco.com) where the agency's monitoring is pointed at the Supabase Status page and misses the failure (Supabase Status shows green because functions.supabase.co is healthy; the failure is at the CF/Fastly/CloudFront edge), JWT-authenticated function calls breaking inconsistently across browsers when the API gateway cert expires mid-session (Edge users see the warning immediately; Safari users with TLS session resumption continue 18 minutes from the cached session; Chrome users hard-block via cached HSTS; Supabase's internal anomaly detection doesn't trigger because it's seeing 12% of normal traffic, not 0%), and `pg_net` Database Webhook targets failing silently when the partner endpoint cert expires with failed events accumulating in net._http_response but never propagating to typical observability stacks.
Most production Supabase Edge Functions deployments don't expose the raw <ref>.supabase.co/functions/v1/<fn> URL to customers. Agencies put a CDN (Cloudflare, Fastly, AWS CloudFront) in front, exposing api.clientco.com/v1/<fn>. SSL termination happens at the CDN; the CDN re-encrypts upstream to functions.supabase.co. Cert expiry on api.clientco.com breaks the customer's frontend; the upstream Supabase URL is still healthy — Supabase Status shows green. Agency monitoring pointed at the Supabase Status page misses the failure entirely. Discovery commonly happens via a Fortune-500 client's monitoring catching the cert error before the agency's does — at which point the customer is already 4-8 hours into a revenue-impacting outage and the support-ticket escalation is in the hands of the customer's CISO
A Supabase Edge Functions agency operates the public API for a B2B SaaS via Cloudflare in front of functions.supabase.co. The pattern: api.clientco.com/v1/process-order routes through CF, CF terminates TLS, CF proxies to projectref.supabase.co/functions/v1/process-order. Cert expiry on api.clientco.com because the customer's Cloudflare account got migrated to a different team during an org restructuring (the new team didn't bring over the universal SSL coverage; the cert silently lapsed). For 8 hours every customer API call hits the Cloudflare cert warning. Mobile app retries fail. Revenue churn that day is $48k. The agency's monitoring was pointed at the Supabase Status page which shows all green. Discovery happens via a customer support ticket from a Fortune-500 client whose monitoring infrastructure caught it before the agency's did
A Supabase Edge Functions agency operates the public API for ClientCo, a B2B SaaS doing $22M ARR. The architecture: ClientCo's mobile app and web app call api.clientco.com/v1/<fn-name> for every business operation (order processing, user lookup, billing events, notifications). api.clientco.com is a Cloudflare proxied hostname; CF terminates TLS at the edge using ClientCo's Cloudflare-managed cert; CF proxies the request to the upstream origin which is configured as projectref.supabase.co. The Supabase Edge Function at projectref.supabase.co/functions/v1/<fn-name> processes the request and returns. The pattern works: low latency (CF's edge is closer to most customers than functions.supabase.co), JWT-bearing requests flow through unchanged (CF passes the Authorization header), and the customer's frontend never knows about the underlying Supabase project. ClientCo's parent company restructures 3 months ago; the security/infrastructure team that managed the Cloudflare account is reorganized. The Cloudflare account ownership transfers from the dissolved security team to a new platform-engineering team. The transfer goes through CF's billing transfer flow; the new team takes over the account; everything looks fine. But the universal SSL coverage on api.clientco.com (which was an explicit per-zone setting in the previous team's account) didn't carry over — the new team's default zone configuration didn't enable universal SSL on the api subdomain. The existing cert continues serving for 90 days from the last issuance. Cert expires on a Tuesday at 02:00 UTC. From that point, every request to api.clientco.com hits a Cloudflare cert warning page (the cert expiry chains through CF's edge — CF is the TLS terminator). The customer's frontend (web + mobile) makes API calls; every call hard-fails at the TLS layer. Web users in Chrome see `NET::ERR_CERT_DATE_INVALID`; web users in Safari see the Safari cert warning; mobile app users see retry-loop failures (the iOS/Android SDKs' TLS validation hard-rejects expired certs). The agency's monitoring strategy: a Better Stack synthetic monitor pinging the upstream functions.supabase.co URL (because that's the Supabase-owned health surface), plus subscription to the Supabase Status page (status.supabase.com) for vendor incidents. functions.supabase.co is up — the upstream is healthy because Supabase's own apex with Supabase's own cert is fine. Supabase Status shows green — there's no Supabase-side incident. The agency's monitoring shows green. ClientCo's frontend, however, is hard-blocked. Customer support tickets begin landing within 20 minutes of cert expiry. By 06:00 UTC (4 hours after cert expiry), 47 support tickets are logged. ClientCo's support team triages: they're internal users, they don't have visibility into the underlying TLS layer; they assume it's a "temporary issue" and respond with apologies. At 09:00 UTC (7 hours after cert expiry), a Fortune-500 client of ClientCo's — the kind of customer ClientCo's sales team has spent 18 months courting — opens a P0 ticket: "Your API endpoint api.clientco.com is presenting an expired certificate. Per our security policy this is a critical finding; we are halting all integration testing until resolved. Please confirm root-cause and ETA. CC: our CISO." ClientCo's account team escalates immediately to ClientCo's CTO. ClientCo's CTO escalates to the agency. The agency engineer pulls up CF dashboard, sees the cert-expiry alert that CF surfaces in the SSL/TLS section but that the new platform-engineering team hadn't wired to alerts. Cert renewal is initiated; CF reissues the cert via the universal SSL flow; cert is live within 20 minutes. Total cert-expired window: 7.5 hours. Revenue impact: ClientCo runs payment-flow telemetry — during the 7.5-hour window, $48k of would-be transactions failed. The Fortune-500 client's P0 finding becomes a permanent line item in their security-assessment file; the deal's closing-conditions list grows by 3 items. ClientCo's engagement contract with the agency includes uptime SLAs at the customer-facing layer (not just the Supabase layer); the SLA is breached. The agency's monthly engagement contract triggers per-incident penalty.
Supabase Edge Functions verify the user's Supabase JWT (anon key or service role) via the `Authorization: Bearer <token>` header. The JWT is fetched by the client SDK on session start and refreshed every 60 minutes (default). Cert expiry on the customer-facing API gateway (the CDN domain in front of functions.supabase.co) breaks JWT-bearing request transmission. Worse — TLS session resumption + browser cert-error caching create inconsistent behavior across users. Edge users see the warning immediately; Safari users with TLS session resumption continue making requests for 18 minutes from the cached session; Chrome users with cached HSTS state hard-block. Supabase Edge Functions itself shows no anomaly (it's only receiving 12% of the usual traffic, not 0%, so internal anomaly detection doesn't trigger). The agency's monitoring sees "elevated 4xx" but the volume looks like a normal Monday morning surge
A Supabase Edge Functions agency operates an authenticated workflow tool with Supabase Edge Functions backing every API call. Cert expiry on api.workflow-tool.com at 02:00 UTC. Edge browser users see the warning page immediately. Safari users with TLS session resumption continue making requests for 18 minutes from the cached session. Chrome users with cached HSTS state hard-block. Supabase Edge Functions itself shows no anomaly (it's only receiving 12% of the usual traffic, not 0%, so internal anomaly detection doesn't trigger). The agency's monitoring sees "elevated 4xx" but the 4xx volume looks like a normal Monday morning surge. Discovery delayed 4 hours. In that window, 220 customer accounts had session-expiry-driven re-auth flows that failed; 38 customers churned the next week
A Supabase Edge Functions agency operates WorkflowTool, an authenticated B2B productivity app with 8,400 paying accounts. The app architecture: React frontend served from Vercel at app.workflow-tool.com; API tier at api.workflow-tool.com (a Cloudflare-fronted proxy in front of functions.supabase.co); auth via Supabase Auth (the supabase-js SDK fetches a JWT on session start; JWT TTL is 1 hour; refresh-token-driven refresh happens automatically every 60 minutes). Every API call from the frontend includes `Authorization: Bearer <jwt>` and routes to api.workflow-tool.com/v1/<fn-name> — CF terminates TLS, CF proxies to projectref.supabase.co/functions/v1/<fn-name>. The Edge Function verifies the JWT against the Supabase project's JWT secret, processes the request, returns. The cert on api.workflow-tool.com is managed via CF universal SSL with a 90-day rotation. The cert expires on a Monday at 02:00 UTC due to a CAA-tightening incident the previous week — the customer's security team had tightened the CAA on workflow-tool.com to remove Let's Encrypt; CF's universal SSL renewal hit the tightened CAA and failed; the renewal failure didn't propagate to the agency's alerting because CF's SSL/TLS section alerts only surface in the dashboard. From 02:00 UTC, browser behavior diverges by browser engine and TLS state. Edge browser users (the smallest user segment, ~8% of WorkflowTool's base) see a Microsoft Defender SmartScreen cert warning immediately; most don't click through. Safari users (~22% of the base) with TLS session resumption (Safari aggressively reuses TLS sessions for the same hostname; sessions are valid for up to 24 hours) continue making API calls successfully for an average of 18 minutes per user from the cached session — the cached session was negotiated against the old (still-valid) cert; the session ID is reused; the cert is never re-validated within that session window. Chrome users (~58% of the base) with cached HSTS state hard-block — Chrome's HSTS cache forces strict cert validation; the expired cert is rejected; the request never reaches CF. Firefox users (~12%) behave like Chrome. Mobile app users (the iOS/Android native apps using a separate URLSession/OkHttp stack) hard-fail with TLS validation errors. Net effect: traffic to functions.supabase.co (which is what Supabase Edge Functions sees) drops to ~12% of normal — the Safari TLS-session-resumption cohort. Supabase's internal anomaly detection on per-project Edge Function traffic is configured for "drops below 5% of historical baseline" — 12% doesn't trigger. The agency's monitoring sees the 4xx rate elevated on the CF side (CF is returning 526 "invalid SSL certificate" for the Chrome+Edge+Firefox cohort). The 4xx rate is elevated 6x but the absolute volume looks comparable to a normal Monday morning surge — Mondays at 09:00 UTC are WorkflowTool's peak traffic window with naturally elevated 4xx from session-expiry / re-auth flows. The agency's on-call engineer glances at the dashboard at 02:30, 03:00, 04:00 — sees elevated 4xx, attributes it to expected Monday surge. Discovery doesn't happen until 06:00 UTC when the agency's SRE lead does the daily standup-prep dashboard review and notices the per-region breakdown shows the 4xx anomaly is concentrated in browser sessions, not API-token sessions. SRE pulls up CF's SSL/TLS section, sees the cert-expiry alert at 02:00. Cert is rotated through CF's manual flow (an emergency Sectigo cert is provisioned because LE is still CAA-blocked) within 90 minutes. Cert is live by 07:30 UTC. Total cert-expired window: 5.5 hours. Customer impact: in the 5.5-hour window, 1,840 user sessions had their hourly JWT refresh fail. The supabase-js SDK's default behavior on auth failure is to redirect the user to the auth-callback URL; the auth-callback URL also routes through api.workflow-tool.com; the auth flow itself fails with cert errors. 220 customer accounts had session-expiry-driven re-auth flows fail completely (their refresh token expired; they were redirected to login; login failed; they couldn't recover the session). 38 of those 220 customers churned the next week — exit interviews cited "the platform was completely broken Monday morning when I tried to start my week." Net MRR impact: $11k. The agency's engagement contract has a customer-experience SLA tied to MRR retention; the SLA is breached for the quarter.
Supabase Database Webhooks (the `pg_net` extension layered on the Edge Functions runtime) call out to HTTPS endpoints on row INSERT/UPDATE/DELETE events. Webhook targets are often external partner APIs (Stripe, HubSpot, Slack, Twilio, customer CRMs). Cert expiry on the target causes the webhook request to fail; the Supabase webhook configuration has a default 3-retry policy and then marks the event as failed; failed webhook events accumulate in `net._http_response` but don't trigger automatic alerts. The agency's on-call rotation doesn't see the database-level failures because Supabase doesn't propagate them to typical observability stacks (Datadog, PagerDuty, Slack) without explicit log-export configuration. Impact surfaces only when downstream business processes (customer onboarding, payments, support routing) visibly break
A Supabase Edge Functions agency operates a customer-onboarding flow where INSERT INTO new_customers triggers a `pg_net` webhook to the client's Stripe Connect platform endpoint to provision a sub-account. The Stripe Connect endpoint cert expires (the client manages that endpoint independently). Over 5 days, 340 new-customer INSERTs trigger webhook failures. The failures accumulate in net._http_response with status_code: 0 and error_msg containing the TLS-handshake failure. No alert fires. The 340 customers can't transact (their sub-accounts don't exist on the platform). Customer-support ticket volume spikes. The agency's on-call rotation doesn't see the database-level failures (Supabase doesn't propagate them to typical observability stacks). Revenue impact is $180k over the 5-day window. The agency's engagement triggers indemnity
A Supabase Edge Functions agency operates the customer-onboarding pipeline for ClientPlatform, a B2B marketplace where new customers sign up to become sellers and need a Stripe Connect sub-account provisioned. The architecture: customer signs up via the ClientPlatform frontend; signup form POSTs to a Supabase Edge Function (functions/v1/signup); the function INSERTs a row into the new_customers table in Supabase Postgres; the INSERT fires a Database Webhook (configured via the `pg_net` extension) that POSTs the new-customer payload to ClientPlatform's internal Stripe-Connect-provisioning endpoint at provision.clientplatform.com/connect/create-sub-account. ClientPlatform's provisioning endpoint receives the webhook, calls Stripe's Connect API to create a sub-account, stores the sub-account ID in ClientPlatform's own DB, and POSTs an acknowledgment back to the Supabase project. The webhook configuration in Supabase: 3 retries with exponential backoff (Supabase's default for Database Webhooks); after 3 failures, the event is marked failed and recorded in net._http_response with a non-2xx status code (or status_code: 0 if the request never completed). On a Friday afternoon, ClientPlatform's provisioning endpoint cert expires. ClientPlatform manages provision.clientplatform.com independently — they have their own ops team running it on AWS ECS behind an ALB; the ALB cert is provisioned via ACM with auto-renewal. The auto-renewal failed two weeks ago because of an IAM permissions change that revoked ACM's ability to write to the Route 53 zone for DNS-01 validation; ClientPlatform's ops team didn't notice the failed renewal because the alerting was misconfigured (PagerDuty integration was set up but the routing rule was wrong; the alert went to a deprecated email distribution list). Cert expires Friday 17:00 UTC. From that point, the agency's Supabase Database Webhook calling provision.clientplatform.com/connect/create-sub-account fails at the TLS layer. Supabase's webhook execution: pg_net submits the HTTPS POST; the underlying libcurl-equivalent rejects the expired cert (Supabase's pg_net doesn't allow disabling cert validation by default); the request fails with a TLS error; the response is recorded in net._http_response with status_code: 0 and error_msg containing the TLS-handshake-failure detail. Supabase's webhook retry logic kicks in: 3 retries with exponential backoff (15s, 60s, 300s by default). All 3 retries fail identically. The event is marked failed. The first new-customer INSERT after cert expiry happens at 17:23 Friday. The webhook fails. The customer signs up, sees the "welcome!" success page, but their Stripe sub-account was never created. The customer can't accept payments (their Connect sub-account doesn't exist on Stripe; ClientPlatform's checkout flow can't route to a non-existent sub-account). Over the next 5 days (Friday 17:00 through Wednesday morning), 340 new-customer INSERTs trigger webhook failures. Each failure accumulates in net._http_response. The agency's on-call rotation uses Datadog + PagerDuty; the agency hadn't configured a Datadog log-stream from net._http_response to a metric (configuring this requires a custom polling job because Supabase doesn't natively export pg_net telemetry to external observability stacks). The agency's monitoring sees normal Edge Function traffic (signups are succeeding at the function level — the INSERT works; the function returns 200 to the frontend), normal Postgres connection counts, normal Supabase status. No alert fires anywhere in the agency's stack for the 5-day window. Discovery happens Wednesday morning when ClientPlatform's customer-support team flags a spike in support tickets: "I signed up but I can't accept payments." The support team escalates to ClientPlatform's product team. ClientPlatform's product team runs a query against the new_customers table: 340 customers signed up in the past 5 days; 0 of them have a Stripe sub-account ID populated. ClientPlatform's product team escalates to the agency. The agency engineer triages: queries net._http_response for the past week, sees 1020 failed webhook attempts (340 events × 3 retries each + the initial attempts) all with status_code: 0 against provision.clientplatform.com. Identifies the cert-expiry root cause; notifies ClientPlatform; ClientPlatform's ops team renews the cert (manually issuing via ACM after fixing the IAM permissions); cert is live by Wednesday 14:00 UTC. The agency engineer manually re-fires the 340 failed webhooks via a one-off SQL script that re-INSERTs trigger rows; the webhooks succeed; 340 sub-accounts are provisioned. But 340 customers had a 5-day window where they couldn't transact. ClientPlatform's Friday-through-Wednesday revenue impact: $180k of GMV that didn't flow through the platform (these were new customers who would have started transacting in their first week). ClientPlatform's contract with the agency has an indemnity clause for downstream customer impact attributable to the integration; the indemnity is triggered. The agency's E&O policy is triggered. ClientPlatform's next quarterly business review with the agency includes a formal escalation; the agency loses the renewal.
How it works
SSL and DNS monitoring for Supabase Edge Functions agencies across the CDN-fronted customer apex (api.clientco.com), the <project-ref>.supabase.co/functions/v1/ upstream, and `pg_net` Database Webhook targets — because each surface has independent cert state and Supabase Status only covers one of them.
Merlonix monitors SSL expiry and DNS integrity across every customer-facing apex routing through CF/Fastly/CloudFront to functions.supabase.co — api.*, app.*, www.* — plus the upstream <project-ref>.supabase.co as a separate asset (because its cert state is Supabase-managed and independent of the customer apex), and the cert state of every documented `pg_net` Database Webhook target — and catches the divergence where the customer apex hard-fails while Supabase Status shows green, the JWT-bearing-request break across browser TLS-session-resumption + HSTS-cache states, and the silent webhook failures accumulating in net._http_response with no alert wiring. Each asset gets independent monitoring because the CDN-front cert state is independent of the Supabase upstream cert state.
01
Add every customer-facing apex in front of Supabase Edge Functions — api.*, app.*, www.* — plus the upstream <project-ref>.supabase.co as a separate asset, with DNS TXT verification that catches CDN-side cert expiry 30 days before customer support tickets land
Verify ownership with a DNS TXT record on the customer apex domain. All customer-facing subdomains routing through CF/Fastly/CloudFront to functions.supabase.co — api.* (the dominant pattern), app.* (when the React frontend and API tier share a domain), www.* — are added without additional verification. The upstream <project-ref>.supabase.co is added as a separate asset because its cert state is independent of the customer apex cert state (Supabase manages the supabase.co cert; the customer or agency manages the api.clientco.com cert through CF/Fastly/CloudFront). Monitoring both surfaces gets the divergence — customer apex hard-fails while functions.supabase.co stays healthy and Supabase Status shows green — surfaces in the first check cycle. Under two minutes per project.
02
CAA inheritance monitoring across customer security-team CAA tightening, Cloudflare account ownership transfers, Fastly TLS configuration drift, and AWS ACM auto-renewal failures — surfacing the changes that silently break universal SSL on the customer-facing apex
Three independent DNS resolvers check every CAA record and CNAME on every monitoring interval, walking the CAA inheritance chain from the apex. When a customer security team tightens CAA mid-cert-cycle (removing Let's Encrypt during a SOC 2 hardening project, breaking CF universal SSL renewal), or a Cloudflare account ownership transfer drops universal SSL on a subdomain, or AWS ACM's DNS-01 validation gets revoked by an IAM permissions change, the configuration drift is detected in the first check cycle — well before the existing cert hits its 90-day expiry and the customer-facing apex starts hard-blocking JWT-bearing function calls.
03
SSL monitoring 30 days before expiry across every customer-facing apex plus the <project-ref>.supabase.co upstream — independent per-asset checks because the CDN-front cert state is independent of the Supabase-managed upstream cert state
Full SSL chain validation on every customer-facing apex routing through a CDN to Supabase Edge Functions. Independent checks per-asset catch cert expiry 30 days before the failure window opens — enough time to coordinate any CA migration with the customer's security team if the apex CAA has been tightened mid-cycle, switch to a Sectigo or DigiCert cert if Cloudflare/Fastly/ACM's native LE integration can't be used, and avoid Monday-morning peak-traffic collisions where the inconsistent browser behavior across Edge / Safari / Chrome / mobile-app TLS stacks delays discovery by 4+ hours.
04
Vendor status for the Supabase Status page, Cloudflare (most Supabase deployments front their custom domain with CF), Fastly, AWS CloudFront, the `pg_net` extension, Stripe / HubSpot / Slack / Twilio (common webhook targets), and Let's Encrypt — to distinguish vendor-side incidents from per-tenant SSL configuration failures
Merlonix monitors the Supabase Status page alongside Cloudflare, Fastly, and AWS CloudFront (the dominant CDN choices in front of functions.supabase.co), the `pg_net` extension as documented on the Supabase docs, plus the common Database Webhook targets (Stripe, HubSpot, Slack, Twilio, customer CRMs) and Let's Encrypt — so when a Stripe API endpoint cert has an issue that's causing pg_net webhook failures across multiple Supabase tenants simultaneously, you see the vendor event clearly rather than spending hours triaging whether the root cause is the customer apex cert, the CF universal SSL config, the ACM auto-renewal, or a genuine partner-endpoint outage.
What the numbers mean for Supabase Edge Functions agencies
Monitoring built for Supabase Edge Functions agencies where one client project means a customer-facing api.clientco.com on a CDN-controlled apex (CF / Fastly / CloudFront), an upstream <project-ref>.supabase.co with Supabase-managed certs, JWT-bearing browser sessions whose behavior diverges across TLS-session-resumption + HSTS-cache states when the API gateway cert expires, and `pg_net` Database Webhook targets pointed at partner APIs (Stripe, HubSpot, Slack, Twilio) where cert expiry on the partner side accumulates in net._http_response with no alerting — each with independent failure modes that Supabase Status won't surface.
Supabase Edge Functions agencies running CDN-fronted production deployments with JWT-authenticated function calls and `pg_net` Database Webhooks calling partner APIs need monitoring that recognizes each surface has independent failure modes — because the cert expiry on api.clientco.com is silent (functions.supabase.co stays healthy; Supabase Status shows green; agency monitoring pointed at the Supabase status page misses it; discovery happens via a Fortune-500 client's monitoring catching it before the agency's does), the JWT-bearing-request break when the API-gateway cert expires mid-session is silent (Safari users with TLS session resumption continue 18 minutes from the cached session; Supabase Edge Functions itself sees 12% of normal traffic, not 0%, so internal anomaly detection doesn't trigger; the agency's 4xx alert looks like a normal Monday morning surge), and the `pg_net` webhook failures against expired-cert partner endpoints are silent (failed events accumulate in net._http_response; Supabase doesn't propagate them to Datadog / PagerDuty / Slack without explicit log-export configuration; impact surfaces only when downstream customer onboarding visibly breaks).
< 10 min
Time from DNS change to alert — catches CAA tightening introduced by customer SOC 2 hardening that silently breaks CF universal SSL renewal on the api.clientco.com apex in front of functions.supabase.co, plus Cloudflare account ownership transfers that drop universal SSL coverage on a subdomain after an org restructuring, and AWS ACM DNS-01 validation breaks after an IAM permissions change
30 days
SSL expiry warning lead time — enough time to coordinate a CA migration with the customer's security team if the apex CAA has been tightened mid-cycle, switch to a Sectigo / DigiCert cert if CF/Fastly/ACM's native LE integration can't be used, or restore CF universal SSL on a subdomain after an account ownership transfer dropped it — before the existing cert expires and the customer-facing apex starts hard-blocking JWT-bearing function calls
11 vendors
Upstream services monitored — Supabase Status, Cloudflare (Workers + DNS, most Supabase deployments front their custom domain with CF), Fastly, AWS CloudFront, the `pg_net` extension, Stripe / HubSpot / Slack / Twilio (common Database Webhook targets), and Let's Encrypt. Distinguishes a vendor-side incident from a per-tenant SSL configuration failure
200 assets
Maximum monitored domains on the Agency plan — covers a full Supabase Edge Functions client portfolio: 50+ Supabase projects each with api.* + app.* + www.* on the customer apex (CDN-fronted) plus the <project-ref>.supabase.co upstream, plus pg_net Database Webhook target endpoints. Multi-region CDN deployments and per-environment staging Supabase projects are absorbed without per-asset fees
Pricing
Flat monthly fee. Every customer-facing apex, every <project-ref>.supabase.co upstream, every `pg_net` Database Webhook target included.
No per-project charges. No per-function fees. Pick the tier that fits your Supabase portfolio and monitor every CDN-fronted apex plus the functions.supabase.co upstream without billing surprises.
Starter
For solo Supabase developers managing a single client project — one Supabase project + custom-domain pattern with api.* fronted by Cloudflare in front of functions.supabase.co, plus the upstream <project-ref>.supabase.co monitored separately.
$29/ month
- 10 monitored assets
- 1 seat
- 15-min check cadence
- SSL + DNS + vendor monitoring
- Email + Slack alerts
Team
For Supabase Edge Functions agencies managing 5-10 client Supabase projects with the custom-domain pattern (api.* + app.* fronted by CF/Fastly in front of functions.supabase.co) plus a few `pg_net` Database Webhook targets per project where partner-endpoint cert expiry can break customer onboarding.
$79/ month
- 50 monitored assets
- 5 seats
- 10-min check cadence
- SSL + DNS + vendor monitoring
- Email + Slack alerts
Agency
For agencies with a full Supabase Edge Functions client roster including SOC 2-hardened customer apexes with CAA tightening that breaks CF universal SSL renewal, JWT-authenticated workflow tools where mid-session cert expiry creates browser-engine-divergent failures, and `pg_net` Database Webhook portfolios calling Stripe / HubSpot / Slack / Twilio across 50+ Supabase projects.
$199/ month
- 200 monitored assets
- 15 seats
- 5-min check cadence
- SSL + DNS + vendor monitoring
- Email + Slack alerts
Know when api.clientco.com is hard-failing the TLS handshake — 4 hours before a Fortune-500 client's P0 ticket lands and the customer's CISO is CC'd on the escalation.
Add your first Supabase Edge Functions custom domain in under two minutes. CDN-fronted customer apexes, the <project-ref>.supabase.co upstream, and `pg_net` Database Webhook target endpoints are monitored from the same dashboard. 14-day trial, no card required.