Status

Cirata Symphony provides real-time visibility into platform health and extension connectivity. This page covers the health check endpoint, extension status tracking, and log access. For OTLP metrics and deeper observability, see the Monitoring overview.

Health Check

The /api/v1/ping endpoint provides a simple, unauthenticated health check that returns:

{"message": "pong"}

Use this endpoint for load balancer health checks, uptime monitors, and automated deployment verification.

curl https://nats://your-symphony-instance.com:4222/api/v1/ping

Instance Information

The /api/v1/symphonyinfo endpoint returns details about the running Symphony instance without requiring authentication:

# Via the API
curl https://nats://your-symphony-instance.com:4222/api/v1/symphonyinfo

# Via the CLI
cirata info

The response includes the instance name, short name, version, NATS connection address, and OIDC provider configuration.

Extension Status

Extensions maintain their presence through a heartbeat mechanism. Each connected extension publishes a status entry to a key-value bucket every 30 seconds. Entries have a time-to-live—if an extension stops publishing, its entry expires and is automatically removed. Symphony watches for these changes and updates the UI in real time.

If an extension crashes, loses network connectivity, or is shut down, it disappears from the status display within approximately 60 seconds.

Status Indicators

The UI displays extension status using colour-coded indicators:

Colour	Status	Meaning
Green	OK	Connected and reporting healthy
Yellow	Warning	Connected but reporting a warning condition
Red	Error	Connected but reporting an error
Grey	Inactive	Registered but not currently connected

The system status indicator in the navigation bar summarises all extensions: green when all are healthy, amber when one or more are disconnected or in a warning state, and red when no extensions are connected.

Status Details

Each extension's status entry includes:

Field	Description
address	Network address of the extension
status	Current status (ok, warning, error)
hostname	Host machine name
cpucount	CPU cores available
heapalloc	Heap memory allocated (bytes)
heapinuse	Heap memory in use (bytes)

Checking Status

UI—the Extensions page shows all registered extensions with status chips indicating their connection state.

CLI:

cirata extension list
cirata extension features

API:

curl -H "Authorization: Bearer $TOKEN" \
  https://nats://your-symphony-instance.com:4222/api/v1/extensions/all

Logs

Symphony emits structured JSON logs to stdout/stderr. No log files are written by the application — log retention is handled by the host environment.

Each log line is a JSON object with consistent fields:

Field	Description
timestamp	ISO 8601 UTC timestamp
level	DEBUG, INFO, WARN, ERROR
message	Human-readable description

Additional fields such as trace_id and span_id are included when a trace span is active, enabling correlation with the Observability pipeline.

On startup, Symphony emits a log entry with "event": "instance.startup" as the first line, making it easy to identify the start of each run.

Viewing logs by installation method

Method	Command
Linux (systemd)	sudo journalctl -u symphony -f
RPM (systemd)	sudo journalctl -u symphony -f
Docker Compose	docker compose logs -f symphony
Kubernetes	kubectl logs -f deployment/symphony

# Linux — view recent logs
sudo journalctl -u symphony --since "1 hour ago"

# Linux — follow in real time
sudo journalctl -u symphony -f

# Docker
docker compose logs -f symphony

# Kubernetes
kubectl logs -f deployment/symphony

Log retention

On Linux (systemd), Symphony ships a journald drop-in configuration that can be installed at /etc/systemd/journald.conf.d/symphony.conf. This ensures logs are stored persistently, compressed, and retained for up to 3 months with a 2 GB disk cap. Without this configuration, some distributions default to volatile journal storage where logs are lost on reboot.

See the Linux Installation guide for setup instructions.

In Docker and Kubernetes, log retention is managed by the container runtime's log driver configuration.

OTLP log pipeline

Independent of stdout, the platform and all extension SDKs buffer log records in memory and expose them via NATS endpoints for the Observability Extension to collect. This provides a second log path for aggregation and querying without modifying stdout output. See Observability for details.

Troubleshooting

Platform not responding

• Verify the Symphony process is running
• Check that the configured port (default 8080) is not blocked
• Review logs for startup errors (see Viewing logs above)
• Ensure the reverse proxy is forwarding requests correctly

Extension not appearing

• Verify the extension can reach the NATS port (default 4222)
• Check that the extension's API key has not been revoked
• Review the extension's own logs for connection errors

Extension showing as inactive (grey)

The extension has registered metadata but is not publishing heartbeats. This typically means the extension process has stopped or lost its NATS connection. Restart the extension and check its logs.

Stale extension entries

Extension entries are automatically removed by the TTL mechanism within 60 seconds of the heartbeat stopping. No manual cleanup is required.

See Also

• Monitoring—OTLP metrics, Grafana setup, and the Observability Extension