This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(99.2, 42%, 19%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ETN%3C/text%3E%3C/svg%3E)
I have a server that supports server-sent events. When running this server locally, everything works as expected.
But as soon as I deploy it in an AKS Kubernetes cluster in front of an Azure Application Gateway for Containers, the SSE connection times out after 60 seconds. After some research, I found the following documentation: https://learn.microsoft.com/en-us/azure/application-gateway/for-containers/server-sent-events?tabs=server-sent-events-gateway-api. There it's stated that you should create a RoutePolicy and configure a timeout of 0s. But doing so doesn't change anything. The observed timeout remains 60s.
I then played around with the RoutePolicy a bit. And in case the timeout is higher than 0s and lower than 300s, the RoutePolicy works. But (as mentioned above) 0s doesn't seem to do anything at all. And any value greater than 300s leads to a 300s timeout. So the 300s appears to be the maximum.
Kubernetes version: 1.29.11.
alb-controller Helm Chart version: 1.3.7
I created a minimal example, which you can find on GitHub: https://github.com/tnotheis/SseServerTest
You can run the SSE server locally with the following command:
dotnet run dotnet run -p .\SseServerTest\SseServerTest.csproj
Afterwards, open http://localhost:5293/sse in your browser. You will receive 1 event per second, which makes it easy to see after which time a timeout occurs.
You will notice that, when running it locally, there will never be a timeout.
I further added a kubernetes.yaml file, which contains all Kubernetes resources necessary to deploy the application into a cluster with an already existing Azure Application Gateway for Containers. Just make sure to replace the name of the gateway resource as well as the hostname (both places are marked with TODO comments).
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(230.39999999999998, 86%, 32%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EAK%3C/text%3E%3C/svg%3E)
Hi Timo Notheisen,
Welcome to the Microsoft Q&A Platform! Thank you for asking your question here
Based on your query,
It is working within the limit of 300 seconds. Beyond that, it does not support. Also, when you set the timeout to 0s, it still times out after 60 seconds. Is that your issue what I have understand if yes means If there are any errors or related logs identified, if possible, could you please share the logs related to this issue? better we can assist more quickly on this thing to address the issue
Hi @Akshay kumar Mandha ,
Thank you for your answer.
Your summary is correct, yes. But unfortunately, there are no error logs - except for the ones on the client side, that say that there was a timeout.
The RoutePolicy is Accepted, no matter if the configured timeout is 0s, 300s or 3600s. There aren't even any Kubernetes events (not even after the first apply). Here's the output of kubectl describe:
Name: sseserver-timeout-policy
Namespace: default
Labels: <none>
Annotations: <none>
API Version: alb.networking.azure.io/v1
Kind: RoutePolicy
Metadata:
Creation Timestamp: 2025-02-04T06:08:02Z
Generation: 1
Resource Version: 67404617
UID: f56b2bd2-3e0e-42a1-a9f3-d47b0b20d8e1
Spec:
Default:
Timeouts:
Route Timeout: 0s
Target Ref:
Group: gateway.networking.k8s.io
Kind: HTTPRoute
Name: sseserver
Namespace: default
Status:
Conditions:
Last Transition Time: 2025-02-04T06:08:02Z
Message: Valid RoutePolicy
Observed Generation: 1
Reason: Accepted
Status: True
Type: Accepted
Events: <none
Hi Timo Notheisen,
Thank you for your reply.
I understand your latest comment. Regardless of the timeout settings, it always times out after 60 seconds. If that is the case, This suggests that the timeout might be overridden, possibly due to an older configuration with a default timeout of 60 seconds in the Ingress. Could you please check the configuration for any default settings that might be causing this issue? Let me know if you find any configuration conflicts
Additionally, as you mentioned that it works locally but encounters issues when deployed in AKS, could you please provide some information on how you set up the SSE locally? It would be helpful to get an overview of the overall setup and the steps you followed for both the local environment and the AKS deployment. This will allow us to identify any potential configuration conflicts or differences
This suggests that the timeout might be overridden, possibly due to an older configuration with a default timeout of 60 seconds
There is no other RoutePolicy anywhere in the whole cluster, if that's what you mean. And I'm not aware of any other way to configure a timeout.
could you please provide some information on how you set up the SSE locally?
I just updated my question with a link to a code example, which should answer your question.
Hi Timo Notheisen,
Thanks for update providing the information
I'm looking into it and will update on this soon
Hi Timo Notheisen,
Thank you so much for your patience while I am reviewing your query. I came across a similar issue case found posted another community member. They have shared some troubleshooting steps that might help resolve your issue. Would you mind taking a look into below link
https://learn.microsoft.com/en-us/answers/questions/2087406/increase-application-gateway-load-balancer-gateway
Please try and let me know
Hi @Akshay kumar Mandha ,
this unfortunately doesn't help. It's about the Azure Application Gateway, while we have problems with the Azure Application Gateway for Containers. As far as I understand, these are two completely different products.