Intermittent 502 HTML pages and SUPABASE_EDGE_RUNTIME_SERVICE_DEGRADED 503s on Edge Function calls in ap-southeast-1

[hungduong-projects]

We are seeing intermittent gateway failures on scheduled calls to Edge Functions across five hosted projects in ap-southeast-1. The failures started around 2026-11-01 19:55 UTC and were still happening at 2026-11-02 03:00 UTC. The status page shows no incident for this period.

Setup

Each project calls its Edge Functions from pg_cron through pg_net. One of those calls runs every 5 minutes in every project.

What we see

In the responses pg_net kept (2026-11-01 21:10 UTC to 2026-11-02 03:08 UTC), 44 of 459 calls failed:

Project	Calls	502	503
A	96	9	3
B	72	5	1
C	144	14	0
D	73	3	1
E	74	5	3

There were no pg_net timeouts in this set.

The two failure types look different:

• 502: an HTML page with <center><h1>502 Bad Gateway</h1></center>, server: cloudflare and a cf-ray ending in SIN. The response has no x-sb-edge-region header.
• 503: the body is {"code":"SUPABASE_EDGE_RUNTIME_SERVICE_DEGRADED","message":"Service is temporarily unavailable"}, with x-sb-edge-region: ap-southeast-1 and a cf-ray ending in SIN.

Successful calls return x-sb-edge-region: ap-southeast-1 through the same colo.

Why this looks platform-side

• Several projects fail in the same minute, for example at 21:25, 21:50 and 22:20 UTC on 2026-11-01.
• Within one minute, one call to a project can return 502 while another call to the same project returns 200.
• All five projects report ACTIVE_HEALTHY, and their databases have not restarted since 2026-10-02.

A sample of 400 unauthenticated calls from outside Supabase, taken once around 2026-11-02 02:00 UTC, returned the expected 401 every time. 125 of them were pinned to ap-southeast-1 with x-region. The failures come in bursts, so this does not show that the region recovered.

Impact

A daily job has no second attempt, so a dropped call loses that day's run. On 2026-11-02 this stopped one daily reminder job from sending its emails until we reran it by hand.

Questions

1. Is there a known issue in ap-southeast-1, and is the gateway 502 related to the degraded 503?
2. SUPABASE_EDGE_RUNTIME_SERVICE_DEGRADED is not listed on the error codes page. #45252 mentions a platform-level retry on degraded responses. Is that retry live, and does it cover calls that come from pg_net?
3. Do you recommend that scheduled callers retry on 502 and 503?

Related

#52588 reports intermittent Cloudflare 502 HTML pages through Seoul on the REST API.

We can share project refs and individual cf-ray values privately with Supabase staff.

[sumit-2007-git]

This behavior (intermittent Cloudflare 502 HTML error pages and SUPABASE_EDGE_RUNTIME_SERVICE_DEGRADED 503s) typically indicates that Edge Function worker instances in the target regional cluster (ap-southeast-1) are either experiencing cold-start timeouts or hit transient gateway worker exhaustion under scheduled cron bursts.

When calling Edge Functions via pg_cron and pg_net:

1. Increase pg_net Request Timeout

The default timeout for net.http_post can be exceeded during Edge Function cold starts:

SELECT net.http_post(
    url := 'https://<project-ref>.supabase.co/functions/v1/<function-name>',
    headers := jsonb_build_object(
        'Content-Type', 'application/json',
        'Authorization', 'Bearer <service-role-key>'
    ),
    body := '{}'::jsonb,
    timeout_milliseconds := 10000 -- Increase from default to 10 seconds
);

2. Implement Exponential Backoff / Retry in SQL Cron Task

Wrap the pg_net call in a stored procedure that checks the return status or retries on 502/503:

CREATE OR REPLACE FUNCTION trigger_edge_function_with_retry()
RETURNS void AS $$
BEGIN
  PERFORM net.http_post(
    url := 'https://<project-ref>.supabase.co/functions/v1/scheduled-task',
    headers := jsonb_build_object('Authorization', 'Bearer <key>'),
    body := '{}'::jsonb,
    timeout_milliseconds := 8000
  );
END;
$$ LANGUAGE plpgsql;

3. Check Edge Function Memory / Boot Time

In the Supabase Dashboard under Edge Functions -> Metrics:

• Check if execution time spikes above the gateway limit on cold starts.
• Ensure heavy module imports (like large npm packages) are loaded lazily where possible to reduce initialization latency.

[hungduong-projects]

thanks, i tried but seem not worked

[sumit-2007-git]

Thanks for testing that out and sharing the update!

Looking closer at your logs (especially the fact that multiple distinct projects failed in the exact same minute with SUPABASE_EDGE_RUNTIME_SERVICE_DEGRADED and Cloudflare 502s without x-sb-edge-region), this is definitely an upstream infrastructure issue on Supabase's regional gateway / Edge Runtime pool in ap-southeast-1 (Singapore) rather than individual function timeouts.

A few clarifications and actionable workarounds you can use right now:

1. Why SQL-level retry is tricky with pg_net

net.http_post is non-blocking (async) — it returns a request_id immediately before the HTTP call finishes. To actually retry failed 502/503 responses, you have to query net._http_response on subsequent cron runs:

-- Check for failed requests in the last hour and re-trigger
DO $$
DECLARE
    r RECORD;
BEGIN
    FOR r IN 
        SELECT id, url 
        FROM net._http_response 
        WHERE status_code IN (502, 503) 
          AND created > now() - interval '1 hour'
    LOOP
        -- Re-dispatch or log alerts
        PERFORM net.http_post(
            url := r.url,
            headers := jsonb_build_object('Content-Type', 'application/json', 'Authorization', 'Bearer <service-role-key>')
        );
    END LOOP;
END $$;

2. Route via a Secondary Region (x-region header)

If ap-southeast-1 edge workers are intermittently degraded, you can force requests to route through a nearby healthy region (e.g., ap-south-1 Mumbai or ap-northeast-1 Tokyo) by passing the x-region header in your pg_net request:

SELECT net.http_post(
    url := 'https://<project-ref>.supabase.co/functions/v1/<function-name>',
    headers := jsonb_build_object(
        'Content-Type', 'application/json',
        'Authorization', 'Bearer <service-role-key>',
        'x-region', 'ap-south-1'  -- Fallback to Mumbai or ap-northeast-1
    )
);

3. Escalate to Supabase Support with CF-Ray traces

Because you have exact CF-Ray IDs, 5 project refs, and synchronized timestamps showing SUPABASE_EDGE_RUNTIME_SERVICE_DEGRADED, please submit a ticket via supabase.help. Mention that the Singapore gateway proxy is dropping upstream connections to the runtime worker pool so the engineering team can inspect the specific worker nodes.

---

If this explanation clarifies the root cause and the x-region / async retry approach helps mitigate your dropped jobs, please consider marking this as the Answer so other developers encountering this in ap-southeast-1 can find it easily!

[PedroCostinha]

One reliability improvement I would prioritize independently of the regional outage investigation is making scheduled jobs recoverable.

net.http_post is asynchronous, so issuing the request is not proof that the remote function completed. The caller needs a separate way to observe the eventual response and reconcile the business operation.

For daily reminder emails, I would use a durable job record with a unique business key, such as recipient + reminder type + scheduled date.

A reconciliation worker can detect failed or unresolved attempts, apply bounded retries with backoff, and prevent duplicate effects using idempotency at the receiving side.

This does not explain the upstream 502/503 errors. It does prevent one transient gateway failure from permanently losing a scheduled operation.

The regional failures still warrant escalation with UTC timestamps and CF-Ray identifiers.