Hello Railway Support,

We are requesting help investigating an intermittent availability event for

our production service during 2026-08-10 03:08:00Z–03:27:00Z.

Observed boundary: Railway's edge intermittently could not establish a

connection to our sole running web service replica. Affected requests showed

three successive five-second connection-dial timeouts before 502 responses.

Requests that reached our Flask application were fast; we have no evidence of

a database failure in the window.

Service identity:

• project alias: maravoa-prod
• environment: production
• service: web
• incident build: 66ade6e
• topology: one web-service replica

Relevant retained observations:

| UTC | Route class | Result |

|---|---|---|

| 03:10:33 | liveness | 502 after roughly 15 seconds; three dial-timeout intervals |

| 03:10:57–03:11:14 | login GET | intermittent 502 / same dial-timeout pattern |

| 03:16–03:19 | liveness and login GET | recovered to 200; the postmortem records recovery without deployment or restart |

| 03:22:21 | liveness | 499 after dial timeout and client close |

| 03:24:35 | root GET | 502 after roughly 15 seconds; same dial-timeout pattern |

| 03:25:37–03:26:21 | login/root/Calendar GET | 200; Calendar completed in 93 ms total / 71 ms upstream |

| 03:26:34–03:26:41 | static asset | roughly 9 seconds wait or 502 after about 15 seconds; app work about 21 ms when reached |

Safe Better Stack response request_id values retained for correlation:

• qsHQw5vbTrOllKg_n6XIxQ
• U-TRCMPVQqCfXbLJxtoGcA
• l-CCdALQReSmwYUDn6XIxQ
• Yd0oXl9aS7meniNFxtoGcA

The retained deployment-list output proves no initiating application deployment

in this window. The contemporaneous internal Aug. 9, 2026 postmortem, rather

than the branch deployment listing, records that no retained evidence indicates

an initiating restart; it also records recovery before any restart/deploy and

the next deployment as the deliberate mitigation at 13:18:05Z.

We identified a separate application-capacity fragility (one synchronous

Gunicorn worker) and later mitigated it with one gthread worker / eight

threads. We do not claim that this caused the recorded edge dial failures.

Could you please determine whether any Railway edge, routing, or

edge-to-replica connectivity event affected this service in that UTC window;

whether the retained request IDs correlate to platform logs; and whether there

was a confirmed platform incident or recommended additional evidence to retain?

Please also state the current-plan retention window separately for application,

deployment, and build logs and for HTTP request logs for maravoa-prod /

production / web.

We are not alleging a proven Railway platform fault. The observed failure

boundary is edge-to-sole-web-replica; the lower-level cause remains unknown.

Thank you.