Monitoring loop

Use the monitoring loop when your team has connected production or post-deploy signals to Coldtea.

This is an enabled-team workflow, not a local default. Some workspaces have monitoring setup and Matcha verification available. Others only have the implementation and review loop. Do not assume monitoring is active until the workspace shows the provider, project, and trigger you expect.

Start with the change

Monitoring should follow the intent of the change. Before a deploy or release, write down:

• What changed.
• Which user path or system behavior should improve.
• Which errors, logs, metrics, or traces would show trouble.
• Which deployment, PR, or environment should be watched.
• How long the watch should matter.

Generic “watch production” instructions are hard to act on. A focused signal is easier to explain and cheaper to trust.

Check provider setup

Monitoring depends on connected systems.

Before relying on the loop, confirm:

• The monitoring provider is connected for the project.
• The provider account has access to the right organization and project.
• GitHub or deployment data is connected if the workflow depends on deploy signals.
• The team has agreed which environments are in scope.
• The surfaced status is current, not stale setup data.

If setup is incomplete, keep review manual. Do not treat missing telemetry as a clean release.

Watch the right window

A useful monitoring window has a start and an end.

The start might be a merge, deployment status, manual release note, or URL becoming available. The end might be a fixed number of hours, a quiet period after traffic resumes, or a team decision that the change is safe.

Coldtea and Matcha-related workflows may surface deployment or verification state where configured. The exact trigger depends on your team setup and build.

Read alerts with context

When a signal appears, read it against the change:

• Is the signal tied to files, routes, services, or behavior touched by the work?
• Did it start after the deploy or already exist before it?
• Is it a hard failure, a warning, or background noise?
• Is the evidence strong enough to create a follow-up task?

Do not hand an agent a raw alert and hope it finds the product story. Give it the task, diff, deploy context, and the specific signal.

Feed issues back into work

When monitoring finds something actionable:

1. Create or reopen the task.
2. Link the deploy, run, alert, or provider evidence.
3. State the expected behavior and observed behavior.
4. Start a focused brew for diagnosis or fix.
5. Run the smallest check that proves the fix.
6. Keep watching the signal after the next change ships.

That is the loop: ship, observe, bring evidence back, fix, and verify again.

Know when it is not proof

A quiet monitoring window is useful, but it is not absolute proof. Traffic may be low. The wrong provider may be connected. The change may not emit the signal you hoped to see.

Write down what was actually watched. “No issues in Sentry for checkout after deploy” is better than “production looks good.”

Next: QA with Matcha for browser verification, or use tasks to keep the follow-up record attached to the work.