Incident investigation configuration reference

Availability: available

Scope: existing incident application

This page documents the current API and project configuration used by the incident web application. Its PostgreSQL, Redis, a single login identity, project credentials, and MENDRY_* settings are not prerequisites of the neutral Agent Harness core. Local and Service Harness composition will have separate validated configuration contracts when those stages ship.

Configuration in the incident application has two scopes: process environment and project-owned runtime configuration. Do not move secrets between them casually.

Process environment

Area	Key examples	Notes
Runtime	MENDRY_ENVIRONMENT, MENDRY_HTTP_ADDR, MENDRY_PUBLIC_URL	Public URL derives webhook URLs and notification console links; use one absolute origin
Data	MENDRY_POSTGRES_URL, MENDRY_REDIS_URL	PostgreSQL is durable; Redis holds sessions
Encryption	MENDRY_ENCRYPTION_KEY	Base64 of 32 bytes; keep stable per database
Auth	MENDRY_AUTH_SESSION_TTL	Defaults to 24 hours
HTTP	MENDRY_HTTP_CORS_ALLOWED_ORIGIN, body/time limits	CORS accepts one exact console origin
Logging	MENDRY_LOG_FORMAT, MENDRY_LOG_LEVEL, MENDRY_LOG_FILE	Production defaults to JSON; local file needs external rotation
Remediation	MENDRY_REMEDIATION_CONCURRENCY, MENDRY_REMEDIATION_RECOVERY_INTERVAL, MENDRY_REMEDIATION_MODEL_TIMEOUT, storage roots, builder digests	Controls execution concurrency, crash recovery, timeouts, and sandboxed builder images

backend/.env.example is the complete current key/default reference. MENDRY_* is the preferred namespace; during the transition, every runtime key also accepts its FIXTHE_* predecessor, and MENDRY_* wins when both are present, including an explicitly empty value. An exported environment variable from either namespace overrides .env values.

Project configuration

A project stores at most one current environment, repository, source, trigger, optional LLM provider, and remediation policy. The draft endpoint returns partial state. Component PUT endpoints update one component without replacing siblings.

Source kinds are ssh, cloud, or mcp; trigger kinds are signed_webhook or custom_rule. Persisting a configuration kind does not by itself prove its runtime connector is available. Check product status.

SSH log monitoring

Choose an ssh source with host deployment and tail mode, then select Managed log probe as the trigger (custom_rule). This path monitors one regular Linux log file and can create incidents without an existing alerting platform. Browse remote files from the source form or enter an absolute readable file path.

Save the source and rules before installing the probe. The host needs Python 3.6 or newer, running systemd, non-interactive sudo -n, and outbound HTTPS access to MENDRY_PUBLIC_URL. Manual rules do not require an LLM; AI rule generation requires a saved provider. After changing the trigger or rotating its token, select Install or update to deploy the current configuration.

See SSH log monitoring for setup, rule semantics, verification, and supported log types.

Remediation policy

Project remediation policy (/configuration/remediation) configures automatic repair boundaries, validation, and change request delivery:

• executionMode: analysis_only (default) or auto_hotfix (Draft PR mode).
• changePolicy: Bounded modifications with allowedPaths (1–64 paths), deniedPaths (forbidden manifests, credentials, and lockfiles), maxChangedFiles (1–30), and maxChangedLines (1–5,000).
• publication: Target branch, Git write credential (gitCredentialSecretId), and SCM provider API secret (scmTokenSecretId).
• validationProfile: Optional local pre-validation sandbox configuration (enabled, imageDigest, workingDirectory, requiredCommands).

Enhanced mode setup can be discovered automatically:

• POST /api/v1/projects/{projectKey}/configuration/auto-hotfix/check starts inspection.
• GET /api/v1/projects/{projectKey}/configuration/auto-hotfix/check polls status (idle, checking, ready, enabled, etc.).
• POST /api/v1/projects/{projectKey}/configuration/auto-hotfix/enable commits the generated profile atomically.

See the automatic hotfix guide for complete workflow and isolation details.

Signed webhook providers

The configuration UI exposes Trigger type, Webhook provider, and the read-only Inbound webhook URL. A signed webhook must be saved before its URL can be generated or rotated. The supported provider values are generic, tencent_cls, and aws_cloudwatch.

Generic and Tencent triggers use schema version 2 with bounded event types and a deduplication key:

{
  "schemaVersion": 2,
  "provider": "generic",
  "eventTypes": ["alarm"],
  "deduplicationKey": "title"
}

AWS CloudWatch displays the additional SNS Topic ARN field. The UI validates that field before enabling save and writes the fixed alarm_arn deduplication contract:

{
  "schemaVersion": 3,
  "provider": "aws_cloudwatch",
  "eventTypes": ["alarm"],
  "deduplicationKey": "alarm_arn",
  "awsCloudWatch": {
    "topicArn": "arn:aws:sns:us-east-1:123456789012:mendry-alarms"
  }
}

See Signed webhooks for provider restrictions, sender setup, rotation, and delivery behavior.

Project notifications

Each project can also store multiple notification channels, configured separately under Configuration → Notifications. Supported platforms are telegram, feishu, wecom, slack, discord, and whatsapp. Channels have a name, enabled state, and encrypted platform credentials; they do not use the shared secret-ID configuration form.

Apply migration 000025_notifications before deploying the notification-enabled API. Notifications reuse MENDRY_ENCRYPTION_KEY for credentials and MENDRY_PUBLIC_URL for incident links. No additional broker or environment keys are required. See project notifications for credentials, event conditions, delivery states, and retry behavior.

Compatibility and telemetry

New sessions use the mendry_session cookie. During the rename transition, the API accepts the legacy fixthe_session cookie and clears it when login or logout sets the current cookie. OpenTelemetry instrumentation and database pool metrics use the mendry namespace, including mendry/backend, mendry.postgres.*, and mendry.redis.*.

Credentials in the configuration components above are separate project records referenced by ID; notification credentials are stored with their channel. Read responses never return plaintext values.

Verified against

• backend/.env.example
• backend/README.md
• backend/docs/automatic-hotfix.md
• backend/docs/remediation-recovery.md