MicroticaMicrotica

Log commands

Stream Microtica build, deployment, and application logs from the CLI, with follow mode, search, failure filtering, and tail.

The logs commands give you one way to read logs across the platform — pipeline builds, environment deployments (CloudFormation or Terraform), and Kubernetes app pods. They share a common set of flags for following, filtering, and bounding output.

All logs commands need a project id. Pass --project <id> or set MICROTICA_PROJECT_ID.

Common flags

Every logs subcommand accepts these:

FlagDescription
-f, --followStream until the run reaches a terminal status.
--since <when>Inclusive lower bound on entry timestamp. Epoch ms or ISO-8601.
--until <when>Exclusive upper bound.
--tail <n>Last N entries only. Implies a snapshot.
--failures-onlyKeep only failure entries. Structural — see notes per command.
--search <pattern>Filter the message with a JavaScript regex.
-i, --ignore-caseMake --search case-insensitive.
--grep-context <n>Lines of context around each --search match.
--timeout <dur>Hard deadline, e.g. 30s, 5m, 1h.
--no-truncateDisable the snapshot byte cap.

Always bound --follow. Follow mode is uncapped and runs until the run finishes. When running unattended, pair it with --timeout, --failures-only, or --search so it can't produce unbounded output.

Output and exit codes

By default the output is human-readable text — one line per entry as <timestamp> <severity> <source> <message> — with a one-line summary on stderr. Add --json (or --query) for NDJSON, where each line is a self-contained JSON object and the final line is an end marker carrying the normalized status.

The logs commands use richer exit codes than the rest of the CLI: 0 success, 1 CLI/API error, 2 the stream didn't end cleanly (interrupted, disconnected, or timed out), 3 the observed result was a failure. You can branch on the exit code instead of parsing output:

Terminal
microtica logs deploy <envId> <deploymentId> --follow --timeout 30m \
  && echo "deploy OK" \
  || echo "deploy failed or dropped (exit $?)"

logs deploy

Stream the events of one environment deployment. The CLI picks the backend automatically from the environment's IaC tool: CloudFormation events for CFN environments, the realtime Terraform stream for Terraform environments.

Terminal
# Tail a running deploy, give up after 20 minutes
microtica logs deploy <envId> <deploymentId> --follow --timeout 20m

# Just the failure events
microtica logs deploy <envId> <deploymentId> --failures-only --json

# Last 50 events only
microtica logs deploy <envId> <deploymentId> --tail 50

To find a deployment id, use pipeline history or env last-deploy.

--failures-only is structural, and CloudFormation-only. It filters on the CFN resource-status enum, so it isn't supported on Terraform deploys or app logs. For free-form patterns like "quota" or "IAM", use --search.

logs build

Stream the per-step log output of a pipeline build.

Terminal
# Watch a running build
microtica logs build <pipelineId> <buildId> --follow --timeout 20m

# Just the failing step, after the fact
microtica logs build <pipelineId> <buildId> --failures-only

# One step, grepping for a pattern
microtica logs build <pipelineId> <buildId> --step build --search "ENOENT" -i
FlagDescription
--step <name>Stream a single step. Default: iterate every step in order.
--rawSend the unfiltered CloudWatch stream instead of the cleaned-up pipeline output.
--no-stitchDisable auto-stitching of a deploy step's deployment events into the stream.

By default, when a build step performs an environment deployment, its CloudFormation or Terraform events are stitched into the same stream alongside the step's output, each tagged with its source. Pass --no-stitch to see only the pipeline step's output.

--failures-only here skips steps that succeeded and marks failing steps' lines as errors. It can't be combined with --follow, since failure can't be known in real time.

logs app

Fetch the logs of a deployed app's pod. This is the same handler as the app logs alias.

Terminal
# Latest snapshot of the app in one environment
microtica logs app <name> --env <envId>

# Grep for errors across the last 200 entries
microtica logs app <name> --env <envId> --tail 200 --search "panic|fatal|ERROR" -i

# Explicit cluster, namespace, and pod
microtica logs app <name> --cluster <clusterId> --namespace <ns> --pod <podName>
FlagDescription
--env <id>Scope cluster/namespace resolution to one environment.
--pod <name>Pod name. Defaults to the first pod.
--cluster <id> / --namespace <ns>Set cluster and namespace explicitly.

App logs are a snapshot. --follow and --failures-only aren't supported for Kubernetes pod logs in this version. Use --search for runtime error patterns, or kubectl logs -f for a live tail. If the app runs in more than one environment, pass --env to disambiguate.

Next steps

On this page