Appearance
Logs
Logs are an organisation-level event stream. Records can carry device, class, application, origin, source type, event type, level, and time context. The Logs workspace combines recent live data with archive queries when archived data is available.
Configure log ingestion from the organisation Logs workspace. Follow its onboarding instructions and source controls instead of treating file paths, systemd units, or commands on an individual device page as managed log sources.
Use logs when
- an alert or incident needs evidence from the same time window
- a device disconnects intermittently
- a rollout changes error volume across a class
- support needs context before starting an interactive session
- security activity needs filtering by actor, device, action, or source
Source and retention boundaries
Source classification is based on fields received with a record and product event classification. A missing or surprising label does not prove that the event was lost.
Dataplicity shows your organisation's retention period in the product. Queries outside that window return no records. Recent live data and archived data can have different delivery delays.
Log ingestion is usage-metered. Check Usage and service limits for your organisation's included units, current usage, and any cap. Avoid publishing secrets or unnecessary personal data in logs.
Place logs in the response
Logs supply evidence; they do not establish ownership, authorise a change, or prove recovery by themselves. Start with the narrowest device and time context, validate the query before widening it, and compare representative records with a healthy peer or earlier window.
Use From signal to verified recovery as the canonical response method. It covers scope, evidence, controlled action, independent verification, and review so those instructions do not drift between concept pages.