Operate Your App
Find and fix what broke in a live app from your terminal: errors, runtime logs, failed deploys and uptime.
Once an app is live, Stardeck records its errors, its runtime logs and every deploy's build logs. Your coding agent reads all of it through the MCP server, so you can ask "anything break overnight?" and have it find the error, fix it, ship the fix and close the issue without opening the dashboard.
What Stardeck records
| What | Recorded for | In the dashboard | Your agent's tools |
|---|---|---|---|
| Errors | Production, previews and the sandbox, local dev included | Settings → Observability → Monitoring | list_project_errors, get_project_error_details, set_project_error_resolved |
| Runtime logs | Production, previews and stagings, up to 3 days back | Not shown | get_worker_logs |
| Deploys | Every production, preview and staging deploy | The app's Deployments page | get_project_deployment_status, list_project_deployment_revisions, get_project_deployment_logs |
| Uptime | URLs you add a monitor for | Settings → Observability → Uptime | list_app_uptime_monitors, get_app_uptime_stats, list_app_uptime_incidents |
| Payment webhooks | Stripe and Beam deliveries to the app | Settings → Services → Payments | list_app_payment_webhook_logs |
| Sandbox output | The cloud sandbox's dev server, build and server logs | The branch's Logs panel | get_app_branch_logs |
Errors need no setup: every deploy, and every local run with a pulled .env.local, reports to the
app's Monitoring tab. Uptime is the exception. Nothing is checked until you
add a monitor.
Most of these tools sit in the catalog, so your agent finds them with search_stardeck_tools
(How tools are disclosed). They follow the role
on your connection:
| To | The connection's role needs | Access |
|---|---|---|
| Read errors and runtime logs | agent:sentry:read | Read only |
| Mark an error resolved | agent:sentry:read | Read & write |
| Read deploy status and build logs | agent:projects:read | Read only |
| Deploy | agent:deployments:write | Read & write |
| Create, change or pause uptime monitors | agent:uptime:manage | Read & write |
Fix an error in production
Find it
Ask your agent what broke. list_project_errors lists unresolved errors grouped by issue,
newest first, with the environments they happened in and how often. To leave out previews and
the sandbox, pass environment: "production".
Read it
get_project_error_details returns the latest occurrence: the exception, the stack trace with
source context, breadcrumbs and the request.
Read the logs around it
get_worker_logs reads the deployed app's console output, request outcomes and status codes. It
looks back an hour by default and up to 3 days, and can filter by text (search) and level
(level: "error"). It never sees a local dev server.
Reproduce it in a test
Have the agent write a workflow test that fails the way production did, then fix the code until
it passes. npm test runs locally against an isolated database. See Testing.
Ship the fix
Push the branch, deploy it as a preview if
you want to click through it, merge its pull request into main, and deploy production. A
production deploy shows you the commit and any destructive schema changes, and runs only after
you confirm.
Close it
set_project_error_resolved marks every occurrence resolved, the same as the Monitoring tab's
Resolve button. If it comes back, list unresolved errors again.
When a deploy fails
See A deploy failed for what the deploy tools show and how to fix it.
Try risky changes on a staging first
Before a production deploy that changes the schema, payments, sent messages or printing, deploy the
branch to a staging: a 24-hour copy of the app on a fresh copy of production's data.
Emails, LINE messages and other sends are captured instead of delivered, and payments use the
playground. Your agent reads what was captured with list_app_staging_captured_sends.
npx @stardeckai/cli deploy --env staging --branch agent/my-changeWatch uptime
Uptime monitoring is off until you add a monitor. Ask your agent to create one for the production
URL (create_app_uptime_monitor), or add it under Settings → Observability → Uptime. Stardeck
then checks it every 5 minutes and alerts you after two failed checks in a row. Intervals, alerts
and PDF reports are on Uptime Monitoring.
Keep the app current
- Updates. Apps get Stardeck's fixes and new features as released updates. See Take an update locally.
- Platform version updates. Older apps that predate the shared foundation take platform updates one step at
a time with
get_app_version_update,prepare_app_version_updateandcomplete_app_version_update. See Tools & Permissions.
Prompts to start from
Anything break overnight on lotus-spa? Check production errors, read the newest one and its logs,
and tell me the cause before changing anything.The last deploy of lotus-spa failed. Read its status and logs, fix the cause on a branch, and
deploy that branch as a preview.Set up an uptime monitor for lotus-spa's production URL and tell me its uptime for the last 7 days.