**Project:** visueal-ed (team: visual-ed), Hobby plan, region iad1
**Runtime:** Container Images, PHP 8.3 + Apache (`php:8.3-apache` base)
## Summary
A deployment that was serving correctly for ~10 hours started failing on every route with `500 INTERNAL_FUNCTION_INVOCATION_FAILED` — including static files like `/favicon.ico`, which never touch our application code. Rebuilding the *exact same commit* (byte-identical Dockerfile, identical base image digest, identical installed package versions) reproduces the failure every time. No application-level log line is ever produced, even when queried live.
## What still works
- `dpl_GPDSngSZqJsyubGFxogStA51q193` (built ~15:36, commit `6999d6e`) — currently promoted, serving 200s normally.
## What fails, every time it's rebuilt
- The same commit (`6999d6e`), rebuilt fresh (e.g. `dpl_FWdams4SmGtFjkXPEsVyZgWTypUH`) — 500 on every route, including `/favicon.ico`.
- Two follow-up commits with unrelated Dockerfile changes (Apache MPM worker caps, then a `$PORT`-aware Apache config per the Container Images docs) — both built successfully (`Ready`, ~55s) and both failed identically at runtime.
## Evidence gathered
1. **Build vs. runtime**: every attempt above shows `readyState: READY` — the build itself always succeeds. The failure is purely at request time.
2. **Image identity confirmed via build logs**: the working and failing builds pulled the identical base image blobs (`sha256:84afdefd22c9c2ddc…`, `sha256:0494d45beee5…`) and the identical config digest (`sha256:37666a60f2922a57da9105cac8b1346062d3097531ffa04230bb07456720aa06`). Package installation logs (`apt-get install`) show the same package list and the same `Fetched 10.0 MB` on both.
3. **No application logs, confirmed two ways**: the dashboard's Logs view (Warning/Error/Fatal filters) shows 0/0/0 for the failing deployment, and a direct `GET /v1/projects/{id}/deployments/{id}/runtime-logs` API call, left open for the full 5-minute query window, returned zero events (only `"Exceeded query duration limit of 5 minutes"` at the end).
4. **Not resource/quota related**: Hobby usage at the time was ~0.05% of Fast Data Transfer and single-digit seconds of Edge Request CPU Duration out of the 1-hour allotment.
5. **Environment variables verified clean** via `GET /v9/projects/{id}/env` — all 15 expected keys present, correctly scoped to production+preview, no stray `PORT` override.
6. **No `vercel.json`** in the repo — relying on Dockerfile.vercel auto-detection only, which is confirmed to work (it's how the currently-live deployment was built).
## What we ruled out on our side
- Apache worker/memory exhaustion (added explicit `MaxRequestWorkers` caps — no change)
- The application code changes in the two follow-up commits (a rebuild of the *original, unmodified* commit fails identically)
- Base image or Debian package drift (byte-identical per build logs)
- Missing/misconfigured environment variables
- Project configuration (`framework`, `rootDirectory`, `buildCommand` etc. all as expected for a container deployment)
## Question
Is this a known issue with Container Images (beta) on Hobby — e.g. something related to cold-start provisioning timing, or a routing issue between the edge and newly-created container instances? Happy to provide any deployment IDs, project ID, or additional detail.