Logs overview

Logs show what your application reported before, during, and after a failure. In Errorgap, logs sit alongside errors, releases, uptime checks, and incidents so you can move from a symptom to the surrounding activity without losing project context.

What logs are for

Use logs when an error group tells you something failed but not enough about what led to the failure. Logs can show request flow, job progress, external service responses, retries, warnings, and other events near the same time window.

• Confirm what happened immediately before an error.
• Search for related warnings or failed retries.
• Compare behavior across environments or releases.
• Collect supporting context for an incident or linked issue.

Open project logs

Logs are scoped to a project. Start from the project that owns the application or service you are investigating, then open the logs view for that project.

1. Open the relevant project.
2. Go to the logs view.
3. Choose the time range or live stream view that matches your investigation.
4. Apply environment and search filters before scanning large log streams.

Filter the stream

Filters keep log review focused. Start broad enough to avoid missing related activity, then narrow the stream as you learn more.

• Environment filters separate production from staging and development.
• Search text can find routes, jobs, request IDs, error messages, or customer-safe identifiers.
• Severity filters help isolate warnings and errors from normal activity.
• Time range filters keep the view close to the event you are reviewing.

Inspect a log entry

A useful log entry should explain what happened and where it happened. When inspecting an entry, look for fields that connect it to the error group, release, request, job, or user workflow you are investigating.

• Timestamp and environment show when and where the entry happened.
• Severity indicates whether the application considered it normal, warning, or failing.
• Message summarizes the event in human-readable form.
• Structured fields can include route, job, request ID, release, or service details.
• Context should be useful without exposing sensitive customer data.

Connect logs to errors

When investigating an error group, use logs to answer what else happened near the same time. Start with the error timestamp, environment, release, and any request or job identifiers visible in the error context.

1. Open the error group and note the latest occurrence time.
2. Open project logs for the same environment and time window.
3. Search for the error message, route, job, request ID, or related service name.
4. Look for warnings, retries, dependency failures, or changed inputs before the error.
5. Add important findings to the linked issue or incident.

Use logs during incidents

During an incident, logs can confirm whether the system is still failing, whether a mitigation is working, and whether the impact is spreading or shrinking. Keep the incident updated with the log evidence behind major decisions.

• Capture the time window where the issue began.
• Watch for repeated failures after each mitigation.
• Compare logs before and after a rollback, deploy, or configuration change.
• Share concise log findings rather than pasting large raw log blocks.

Logging habits

Good logs are specific, structured, and safe to share with teammates. They should help explain behavior without leaking sensitive data.

• Use consistent names for environments, services, routes, and jobs.
• Include request or job identifiers when they are safe and useful.
• Prefer structured fields over long unstructured messages.
• Log important state changes, retries, and dependency failures.
• Redact secrets, credentials, tokens, and sensitive customer data.