ShippedLogs
Go from a failed build or unexpected request to the service that needs attention. Keep deployment evidence close to the application.
Follow a deployment from build to runtime
Inspect build output when packaging fails and application logs when a service starts or handles requests. Keep the target service, environment, and release in view so you do not diagnose staging output as a production problem. Deployment history gives the log entries context, including the source and configuration associated with the change.
Use your portal or coding agent
Read the relevant output in the portal or ask your agent to inspect the application through Shipped MCP. Scope the investigation to the service and time range that matter. Logs complement health and resource information: a process can be running while a specific request fails, and a healthy endpoint does not explain every application error.
Write logs that help without exposing data
Include useful event names, request identifiers, and error context in application logs. Avoid printing passwords, access tokens, payment data, or entire customer records. A clear record of what failed is usually more useful than a large dump of private state, and it is easier to share safely when another person helps investigate the issue.
A little more detail
Questions about Logs?
Are application logs a backup of customer records?
No. Logs support diagnosis and operations. They should not be used as a substitute for database backups or deliberately filled with sensitive customer data.
Will logs show the cause of every outage?
No single signal explains every problem. Use logs together with deployment status, service health, and resource information, then investigate the application or dependency indicated by that evidence.
From your workspace to the web