All articles

Getting Started

What is CICDoo "Getting started: the onboarding wizard" The Dashboard and Infrastructure Map

Concepts

Production, staging and development stages Domains, subdomains and SSL Odoo versions and editions (Community vs Enterprise) Workspaces and team collaboration

Servers

Adding a server Server domains and DNS Using a load balancer "Server actions: deploy, logs and charts"

Projects & Git

Creating a project Connecting GitHub Connecting GitLab Branches and instances

Instances & Console

Creating an instance Restarting, stopping and removing an instance Merging branches between stages Web IDE and remote access Instance settings explained Deployments and the job queue

Monitoring & Backups

Monitoring your instance Backups and restore Alert notifications (email and SMS)

Workspaces & Permissions

Inviting workspace members Member permissions and resource access A member cannot see or use a resource

Account & Security

Two-factor authentication (2FA) Profile and integrations settings Passwords and account recovery

Billing & Plans

"Plans: Free, Pro and Enterprise" Upgrading and managing your subscription What happens when you hit a plan limit

Support & Tickets

Opening a support ticket Getting help from the CICDoo team

Troubleshooting

"Troubleshooting: cannot connect a server" "Troubleshooting: a deployment failed" "Troubleshooting: my instance is down or slow" "Troubleshooting: domain or SSL problems"

Troubleshooting

"Troubleshooting: my instance is down or slow"

The order of checks to run when an instance is unreachable or slow, from status and monitoring charts to restarts and memory limits.

Work through these checks in order

1. Instance status in the console header

Open the instance Console. The header shows a live status indicator next to the branch name. If the instance is not running, an amber banner appears at the top saying "Instance is not running". The banner also tells you whether Auto Restart is enabled; if it is disabled, you can enable it in Settings so the instance recovers automatically after failures.

2. Is the server online?

Check the Servers page. Each server card shows an Online, Offline, Down, or Degraded badge plus live CPU, memory, and disk usage. If the server itself is down, no instance on it will respond; that is a server problem, not an instance problem.

3. Monitoring tab

In the Console, open the Monitoring tab:

  • If uptime monitoring is active, you see the 30-day uptime percentage, average response time, current status, and daily uptime bars.
  • Two charts show CPU and memory usage for the Odoo container and the database container. Sustained 100 percent CPU or memory climbing to a ceiling explains slowness.
  • Click any point on a chart to open the container logs around that moment; you can also drag to zoom and double-click to reset. In the logs panel, the brain icon runs an AI analysis of the log and lets you ask follow-up questions.

4. Logs tab

The Logs tab shows the live Odoo log with Refresh, Stream (auto-refresh), and Download buttons. Look for repeated tracebacks, out-of-memory messages, or a crash loop.

5. Restart

Click Restart in the console header:

  • Try Soft Restart first (restarts Odoo and upgrades modules).
  • If that does not help, use Hard Restart (restarts the Docker container).

6. Recent deployments

Open the Queue tab (or the Queue page) and check whether a recent deploy or upgrade job coincides with the outage. See Troubleshooting: a deployment failed.

If the container keeps dying

A container that repeatedly stops, especially right after startup or under load, is often hitting a memory ceiling. In Settings, Odoo tab, review Memory Limit (MB) (0 means unlimited) and the equivalent fields on the PostgreSQL tab. Raising the limit, or setting it to fit what the server can actually provide, can stop the crash loop. Note that instance tuning settings require a Pro or Enterprise plan.

When to escalate

Open a support ticket (open the article) with Issue Type Instance and the instance attached if the instance stays down after both restarts, or if the cause is not visible in the logs. Include: what the status indicator and offline banner showed, the relevant portion of the Logs tab output, any chart spike you found in Monitoring, and recent Queue jobs.

Previous "Troubleshooting: a deployment failed" Next "Troubleshooting: domain or SSL problems"

Still stuck? Open a ticket from the app or talk to an engineer.