bug: Live Demo API returns 503 and is hardcoded as the frontend production fallback
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 57
- Forks
- 68
- Avg merge
- 3d 15h
- Merged PRs (30d)
- 17
Description
What happened?
The REST API listed under Live Demo in README.md is down. https://openshield-api.onrender.com
returns HTTP 503 on every path, with a Render placeholder page titled Service Suspended:
$ curl -s -o /dev/null -w "%{http_code}\n" https://openshield-api.onrender.com/
503
$ curl -s -o /dev/null -w "%{http_code}\n" https://openshield-api.onrender.com/health
503
$ curl -s -o /dev/null -w "%{http_code}\n" https://openshield-api.onrender.com/api/health
503
The other two services in the same table are fine — the dashboard and the project website both
return 200. This is only the API.
The wider problem is that the URL is not just documentation. It is hardcoded as the production
fallback in the frontend:
frontend/src/utils/api.js:9frontend/src/utils/aiApi.js:15
Both read import.meta.env.DEV ? 'http://localhost:5000' : 'https://openshield-api.onrender.com'.
Unless VITE_API_URL is set in the Vercel project, the deployed dashboard calls a suspended
backend on every page load, and the committed frontend/dist bundle already has the URL baked in.
Seven source files reference it:
| File | Context |
|---|---|
README.md |
Live Demo table, plus the VITE_API_URL= frontend setup snippet |
frontend/src/utils/api.js |
production fallback base URL |
frontend/src/utils/aiApi.js |
production fallback base URL |
website/content.js |
two curl examples shown to visitors, and an FAQ answer |
docs/api-render-deploy.md |
four smoke-test commands |
docs/azure-setup.md |
referenced as the deployed API |
docs/superpowers/plans/2026-07-12-terraform-oidc.md |
planning doc, low priority |
What did you expect?
Either a reachable API behind the documented URL, or documentation and frontend defaults that do
not point at a suspended service.
Steps to reproduce
curl -i https://openshield-api.onrender.com/health— observe 503 and theService Suspendedbody.- Open the deployed dashboard at
https://openshield-gules.vercel.appwithoutVITE_API_URL
configured — API calls resolve to the suspended host. - Follow the README Live Demo table or the
curlexamples on the project website — both fail.
Environment
- OpenShield version:
dev@ f1a7e45 - Python version: n/a (hosting and docs issue)
- OS: n/a
Logs or screenshots
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Service Suspended</title>
</head>
Possible resolutions
Not making the call here — this depends on whether the Render service is coming back.
- Restore the service. Everything above is then correct as written and only the deploy needs attention.
- Retire the hosted API. Drop the Live Demo row or relabel it as suspended, replace the
curl
examples with self-host instructions, and change the frontend fallback tohttp://localhost:5000
(or leave it unset and fail with a clear message) so the dashboard does not silently call a dead host.
Either way the frontend fallback should be addressed, since that is the only part affecting users
rather than readers.
Raised while working on #228 / #230, which touch the same README section but deliberately leave
this alone as out of scope.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the production fallback expressions in frontend/src/utils/api.js and frontend/src/utils/aiApi.js, then trace the seven references listed in the issue. Review the README, website content, and deployment documentation alongside the service status before choosing a direction. Done means the frontend and published examples no longer depend on an unavailable API, with the relevant references consistent.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- cloud, documentation, frontend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100