Last updated:

Logging & Monitoring Policy

Version: 1.0 · Status: Active · Effective: 2026-05-05

1. Purpose

This policy describes the logging, monitoring, and alerting controls that Projan AI Ltd (company number 17196385) maintains across its platform. These controls ensure operational visibility, timely incident detection, and compliance with our data protection obligations.

2. Scope

This policy applies to all production and non-production services that comprise the Projan platform, including application services, supporting infrastructure, and third-party integration points. All services operate under the same logging and monitoring standards described in this document.

3. Logging Standards

Projan employs structured JSON logging across all application services. Every log entry includes a consistent set of fields that identify the originating service, the severity of the event, and a machine-readable event identifier. This structured approach enables efficient searching, filtering, and automated analysis of log data.

Log severity levels follow industry-standard conventions:

  • Debug - detailed operational data used during development and troubleshooting.
  • Info - significant business events and successful operations.
  • Warn - degraded conditions that have been handled but may require attention.
  • Error - failed operations, unhandled exceptions, or service unavailability.

Production environments are configured to capture informational events and above, while non-production environments may capture more verbose output to support development and testing activities.

All services generate a unique correlation identifier for each inbound request. This identifier is propagated through every log entry produced during the lifecycle of that request, enabling end-to-end tracing of operations across service boundaries. Request-scoped context such as user and team identifiers is similarly propagated, ensuring that downstream log entries carry sufficient context for investigation without requiring manual annotation.

4. PII Protection in Logs

Projan applies automatic personally identifiable information (PII) redaction to all log output before it is written to any storage medium. The following controls are enforced:

  • Email addresses are automatically detected and masked so that only a minimal prefix and the domain are visible. The full address is never written to logs.
  • Authentication tokens, API keys, and secrets are automatically truncated to a short, non-usable prefix. Full credential values are never recorded.
  • Passwords are never written to logs under any circumstances.
  • Redaction is applied recursively to all nested data structures within a log entry, ensuring that sensitive values cannot bypass protection through deeply nested payloads.
  • Non-sensitive values such as numeric identifiers and boolean flags pass through without modification.

These protections operate at the logging framework level and are applied uniformly across all services. Individual developers do not need to manually redact sensitive data; the framework handles this automatically.

5. Monitoring and Alerting

Projan uses AWS CloudWatch for infrastructure and application monitoring. Automated alarms are configured for all production and pre-production environments and cover the following categories:

  • Compute utilisation - alarms trigger when CPU or memory consumption exceeds defined thresholds, indicating potential capacity constraints or resource leaks.
  • Service availability - alarms trigger when running service instances drop below expected levels, or when health checks report unhealthy targets.
  • Error rates - alarms trigger when the rate of server-side errors (HTTP 5xx responses) exceeds acceptable levels within a defined observation window.
  • Response latency - alarms trigger when high-percentile response times exceed defined thresholds, indicating degraded user experience.

All alarms are evaluated over multiple consecutive periods before firing to reduce false positives. Missing data is treated appropriately for each alarm type - for example, the absence of health data from a service is treated as a potential outage rather than a healthy state.

Alert notifications are delivered via AWS Simple Notification Service (SNS) to subscribed recipients, ensuring that the operations team is promptly informed of any condition that requires investigation or intervention.

6. Health Checks

All Projan services expose dedicated health check endpoints that are continuously polled by the platform’s load balancing infrastructure. These endpoints verify the availability of the service itself and its critical dependencies, such as database connectivity.

When a health check fails, the infrastructure automatically:

  • Routes traffic away from the unhealthy instance.
  • Triggers replacement of the failed instance.
  • Generates an alert via the monitoring system described in Section 5.

This automated recovery mechanism minimises the duration and impact of individual service instance failures.

7. Dashboards

Projan maintains operational dashboards for each monitored environment. These dashboards provide real-time visibility into:

  • CPU and memory utilisation across all service instances.
  • Request volume - the number of inbound requests processed over time.
  • Response time - both average and high-percentile latency metrics.
  • Error rates - counts of client-side (4xx) and server-side (5xx) HTTP errors.

Dashboards are available to authorised operations personnel and are used for routine operational oversight, capacity planning, and incident investigation.

8. Log Retention

Log data is retained in accordance with the following principles:

  • Development environments - logs are retained for a short period (measured in days) sufficient for active development and debugging.
  • Pre-production environments - logs are retained for a moderate period to support testing and integration validation.
  • Production environments - logs are retained for a longer period (measured in weeks) to support incident investigation, audit requirements, and operational analysis.

Retention periods are configured at the infrastructure level and are automatically enforced. Logs beyond their retention period are permanently deleted.

9. Review Schedule

This policy is reviewed:

  • On a quarterly basis, or
  • When material changes are made to the monitoring or logging infrastructure, or
  • Following any incident in which monitoring gaps are identified.

Next scheduled review: August 2026.

10. Contact

For questions about this policy or to report a concern related to logging and monitoring practices, please contact:

Email: security@projan.ai


Related Policies