PYRONTechly Logging and Monitoring Policy
What Techly records about Pyron and its own systems, what it never records, how long it keeps it, who can read it, and how it is watched.
Purpose
Records of what happened are how a problem is noticed, investigated and proved. This policy sets out what Techly Operations Pty Ltd (Techly) records, what it deliberately leaves out, and how the records are protected and watched.
Scope
Pyron's production service, the cloud accounts it runs in, and the audit trail each workspace keeps.
What is recorded
| Record | What it holds | Where |
|---|---|---|
| The audit trail | Every change in a workspace, whether a person, an automation, the AI or Support made it; what people view; and the attempts the permission engine refused | In the workspace's own data, in Australia |
| Application logs, metrics and traces | How Pyron is running: requests, timings, errors and the work of each service | Grafana Cloud, in Australia |
| Error reports | Application errors, which can contain fragments of the data being processed | Sentry, in the European Union |
| Cloud activity | Every action in Techly's AWS accounts, recorded by AWS CloudTrail | A separate archive account, in Australia |
| Cluster activity | Requests to the Kubernetes cluster's control plane | AWS, in Australia |
| Outbound traffic | The destinations Pyron's servers reach, through Cloudflare Gateway | Cloudflare |
What is never recorded
Before logs and traces leave Pyron's servers, a central filter removes credentials, cookies, authorisation headers, request bodies, database query parameters, what is said to and by the AI, and the inputs and outputs of code a person runs, and masks anything that looks like a key or a token. Error reports carry no request body and no cookie, and pass through the same kind of scrubbing.
Protecting records
- The audit trail can only be added to: Pyron's own database account cannot edit or delete its records, and each record is cryptographically linked to the one before it, so tampering would be evident. Old records are removed only by the retention sweep, which records each removal.
- Cloud activity is copied into a separate archive account, where it is kept under a retention lock for 12 months.
- Access to records is limited to the people whose work needs it. Techly's read-only access for looking at its cloud accounts cannot read the contents of logs.
How long records are kept
As the Techly Records Management Policy says: the audit trail for 24 months, security logs for 12 months, application logs for up to 30 days, and error reports for up to 90 days.
Monitoring
- Alert rules watch Pyron's logs, metrics and traces. They are defined in code, and a test fails if an alert has no written runbook.
- Paging. Serious alerts page the on-call engineer through All Quiet, at any hour. The rest post to Techly's alerts channel.
- Security events. Use of emergency administrator access, a sign-in as a root user, a change to the organisation's policies or to AWS CloudTrail, a change to access assignments, and new outside access to a resource each raise an alert, and the first four page.
- From outside. Synthetic checks test Pyron from outside, and a watchdog pages if the monitoring itself stops reporting.
- Dependencies. A daily scan reports newly published vulnerabilities in what Pyron runs.
An alert is acted on as its runbook says, and anything that might be a security incident is handled under the Techly Incident Management Policy.
Who is responsible
- The Technical Director owns this policy, the alert rules and the runbooks, and is the on-call engineer.
- A workspace's admins read its audit trail in Pyron.
Review
The Technical Director reviews this policy, and whether each alert still earns its place, every year.