App status and logs
Use the console’s status indicators and logs to check whether an app is available and investigate problems. Logs record app activity, errors, and access requests.
App status
Section titled “App status”Status badges appear in the app list and on each app’s page.
| Status | Meaning |
|---|---|
| Active | Recent requests are using one concurrent app slot |
| Sleeping | Deployed, but not using a slot because there have been no recent requests. A stopped app starts automatically on access |
| Published | Serving a static site or SPA. Keelson returns the page files directly |
| Suspended | Manually stopped. Requests do not start the app or resume serving. Data, URL, and configuration are retained |
| Starting / Deploying | Starting or stopping, or applying new code or configuration |
| Not deployed | Created, but not yet deployed |
| Error | The latest deployment or execution failed. The app page shows the cause |
| Deleting | Deletion is in progress. The app disappears from the list when it finishes |
| — | An app that only runs scheduled jobs. Check individual results in the Scheduled Jobs tab |
Active and Sleeping describe usage, not whether a server process is currently alive. Web apps stop after a period without requests and start on the next request. See When apps run.
Apps accessed within the last five minutes normally occupy a slot. Priority startup reserves a slot even without requests. When no slot is available, users see a page asking them to wait. An unreserved slot is released about five minutes after the last request to its app.
An Error badge may refer to the latest failed deployment even while the previous version remains available. Check the failure in Overview and try opening the app.
Suspend and resume
Section titled “Suspend and resume”To temporarily stop an app, open Settings → Suspend on its page. This applies to web apps and static sites or SPAs. While suspended, requests, webhooks, and scheduled jobs do not start it, and static files are not served. The standard Keelson URL shows a stopped page, and custom-domain serving also stops. Data, URLs, and configuration are retained.
Use Resume in the app page header to resume it. Deploying a static site or SPA while it is suspended does not resume serving; you must explicitly resume it. Static serving changes propagate gradually, so stopping or resuming may take a little time.
Apps that only run scheduled jobs have no console Suspend action. To stop their schedules, set each job’s enabled to false and deploy. Set it back to true and deploy to resume. See Scheduled jobs.
Priority startup
Section titled “Priority startup”Turn on Priority start in the app page header to reserve one concurrent app slot. This prevents the app from being blocked because all slots are occupied.
- The app still stops after a period without requests. Users may need to wait for startup on the next request.
- On paid subscriptions, available on Plus and higher plans; you can reserve up to one fewer than your total slot count. During the trial, all plans can enable it for up to 2 apps.
Choose the log that matches what you are investigating.
| What you want to know | Where to look | What it records |
|---|---|---|
| Why a deployment failed | Details for a deployment in Deploys | The failure summary and messages for you, such as warnings about your keelson.yaml. Details appears only on deployments that failed or have warnings |
| Why an action failed in the app | App logs under Logs | Activity and errors written by the app to standard output and standard error |
| Why a user was denied access | Access logs under Logs | Who accessed which path, when, and whether access was allowed or denied |
| Whether a scheduled job succeeded | Run history under Scheduled Jobs | Start time, result, duration, and logs for each run |
Give your agent the app name, time, and what happened:
In this app, [action] produced an error at [date and time]. Check the status and logs, then explain the cause and how to resolve it.
Log ranges and the CLI
Section titled “Log ranges and the CLI”App logs can be filtered between web and scheduled-job (cron) execution. The console shows the most recent 200 lines; exports include up to 5,000 lines. Access logs can be filtered by users, machines (app tokens), and webhooks. Retention depends on your plan.
Use keelson logs from the CLI. For app logs in a format an agent can process, use keelson logs app <slug> --json. See Identify the failing stage for logs to inspect after a failed deployment.
Deployment history and rollback
Section titled “Deployment history and rollback”The Deploys tab lists past deployments. You can download each deployment’s source. Deployments that failed or have warnings also show Details.
A rollback returns the code to an earlier deployment. It does not restore database contents, and static sites or SPAs require redeploying earlier files. See Restore an earlier version of the code for instructions and limits.
Redeploy in the app page header restarts the app using the last successful deployment’s runnable files. Applying secrets also redeploys without uploading or rebuilding the code. See Apply saved values to the app.
Delete an app
Section titled “Delete an app”To retire an app, use Settings → Danger Zone to delete it. Browser approval is required, and you cannot undo the deletion yourself. See Retire an app for what to export first and how long data is retained. Use Suspend above if you only want a temporary stop.