Monitoring and logs

Use the Dashboard and Logs views together. Metrics tell you when service behavior changed. Logs help you find the request or runtime event behind that change.

Service metrics

Open a deployed service and click Dashboard. Select a time range, then refresh to load the latest available data.

The overview includes:

Signal	What to check
Requests	Whether traffic changed from the previous period
Error rate	Whether requests are returning more errors
Response time	Whether the API is responding more slowly
Memory	Whether runtime memory use is growing
Compute	How much runtime capacity is being used
Connections	Current database connection activity

The dashboard also shows recent logs and top endpoints when data is available. New or undeployed services display sample or empty states until they receive traffic.

Runtime logs

Open Logs for the selected service. You can:

Select a time range.
Search message text
Filter by log level
Filter by source
Refresh the current result set
Export the visible logs as JSON

Start with a narrow time range around the failed request. Search for a route, entity name, or exact error message. Level and source filters are useful after you understand which subsystem produced the event.

Build logs

The CLI logs command reads build output for the service linked to the current directory.


apso status
apso logs

Pass a build ID when you need output from a specific build:


apso logs <build-id>

Use dashboard runtime logs for API traffic and apso logs for generation or deployment failures.

Health endpoint

The TypeScript service template includes a basic health route:


curl http://localhost:3100/health


I am up!

This confirms that the application process can answer an HTTP request. Add checks for dependencies your service needs, such as the database or an external provider, in custom code outside src/autogen/.

A useful investigation sequence

Run apso status or open Deployments to confirm the current build completed.
Check Dashboard for a change in errors, response time, memory, or connections.
Open Logs with the smallest useful time range.
Search for the route and compare the response with the service’s Docs view.
Reproduce the request locally with apso dev when the error comes from generated or custom code.
Add a focused test before deploying the fix.

For a schema-related failure, run validation before another deployment:


apso schema validate

Logging from custom code

Log enough context to identify the operation while avoiding credentials and personal data.


this.logger.error('Project archive failed', {
  projectId,
  error: error instanceof Error ? error.message : 'Unknown error',
});

Never log API keys, authorization headers, session tokens, full request bodies, or database connection strings.