CMDash Help: Troubleshooting Guide

This guide is organized by symptom. Find the issue you're experiencing, work through the resolution steps in order, and contact support if the issue persists after completing all steps.

Support channels:

• In-app help: Click the ? icon (or press Shift+/) in the top bar of any page for a contextual panel of tips and documentation links — this panel does not offer a way to contact support directly
• Email: support@cmdash.com — response within 1 business day
• Status page: www.cmdash.com/status — real-time system health
• Enterprise: Contact your dedicated Customer Success Manager

Posture Score Issues

Score didn't update after I fixed a vulnerability

Symptom: You closed or remediated a vulnerability in your scanner or endpoint tool, but the Posture Score in CMDash hasn't changed.

Likely causes:

• The integration hasn't synced since the vulnerability was closed in the source system.
• The vulnerability was marked as suppressed or accepted in the source tool, rather than fully closed.
• A sync delay or temporary integration error is preventing the latest data from loading.

Resolution steps:

1. Check the last sync time. Navigate to Integrations → [integration name] and look at the Last Synced timestamp. If it was more than 15 minutes ago, the sync may be overdue.

2. Manually trigger a sync. Click Sync Now on the integration page. Wait for the sync to complete (the status indicator will return to "Healthy" with a new timestamp).

3. Verify the vulnerability is actually closed in the source tool. Log in to your scanner (e.g., Tenable, Qualys) or endpoint tool (e.g., CrowdStrike, SentinelOne) and confirm the finding has a status of "Fixed," "Closed," or "Resolved" — not "Accepted," "Suppressed," or "Exception." Accepted and suppressed findings are counted as open in CMDash's posture calculation.

4. Wait up to 15 minutes after the sync completes. The Posture Score recalculates after each sync, but the dashboard may take a few moments to reflect the updated score. Reload the page after 15 minutes.

5. Check Score History. Navigate to Dashboard → Score History and confirm whether the score changed after the sync. If the remediated finding was not high-severity or not heavily weighted, the score change may be small.

If the issue persists after a successful sync and the vulnerability is confirmed closed in the source system, contact support with your integration name, the CVE or finding ID, and the date you closed it.

MFA coverage is wrong

Symptom: The MFA Coverage signal shows a percentage that is lower than your internal records indicate.

Likely causes:

• Not all identity providers are connected to CMDash.
• Service accounts or break-glass accounts are being counted in the denominator but are legitimately excluded from MFA requirements.
• The integration credentials lack the API scope required to read MFA enrollment status.
• A sync has not completed recently.

Resolution steps:

1. Confirm all identity providers are connected. Navigate to Integrations and verify you have an active, healthy connection for every IdP in your environment. If your organization uses Okta for employees, Azure AD for cloud resources, and Duo as a secondary factor, all three must be connected. CMDash calculates MFA coverage by aggregating accounts across all connected identity providers.

2. Check integration health and API scopes. Navigate to Integrations → [IdP name] → Credential Scopes. Ensure the credentials have the permissions listed as required for MFA data. For Okta, the required scope is okta.users.read; for Azure AD, it is User.Read.All and Policy.Read.All. If scopes are missing, update the credentials with a token that includes the required permissions, then trigger a manual sync.

3. Review service accounts and break-glass accounts. CMDash does not currently offer a self-service way to exclude specific accounts from the MFA coverage denominator. If your organization has service or emergency-access accounts intentionally excluded from MFA policy, contact support with the account list so the exclusion can be applied on your behalf. (Org-wide MFA requirements are set separately, under Settings → Security → MFA Enforcement Policy.)

4. Trigger a manual sync and wait for it to complete, then reload the dashboard.

If MFA coverage still looks incorrect after all identity providers are connected and scopes are verified, contact support with a list of the identity providers you expect CMDash to cover and the approximate expected user count.

Score dropped after connecting a new integration

Symptom: Your Posture Score decreased — sometimes significantly — immediately after adding a new integration.

This is expected behavior and is a sign the system is working correctly.

Explanation: Before the integration was connected, CMDash had no visibility into the security signals that integration provides. A missing signal is not the same as a passing signal — when a signal category has no data, CMDash scores it conservatively (as a potential gap). However, once you connect the integration, CMDash can evaluate the actual state. If the integration reveals real gaps — unmanaged endpoints, accounts without MFA, unpatched vulnerabilities — the score will reflect those findings accurately for the first time.

What to do:

1. Do not disconnect the integration. Disconnecting it will restore the artificially higher score, but the underlying gaps will still exist — they just won't be measured.

2. Review the findings surfaced by the new integration. Navigate to Dashboard → Signal Details and filter by the newly connected integration to see exactly what is driving the score change.

3. Prioritize remediation. The score will improve as you address the newly surfaced findings. CMDash's Insights panel will recommend the highest-impact actions to take first.

4. Set expectations with stakeholders. If you are reporting the score to a board or executive team, proactively explain that the score temporarily decreased because you increased measurement coverage — this is a sign of a maturing security program, not a regression.

Integration Issues

Integration shows "Unhealthy" or "Error"

Symptom: One or more integrations display a red "Unhealthy" or "Error" status on the Integrations page.

Likely causes:

• API credentials have expired or been rotated in the source system.
• CMDash's IP addresses are blocked by a firewall.
• The source system's API is rate-limiting CMDash requests.
• A known incident is affecting either CMDash or the source system.

Resolution steps:

1. Check the CMDash status page. Visit www.cmdash.com/status to see if there are active incidents affecting integrations. Also check the source vendor's status page (e.g., trust.crowdstrike.com, status.okta.com).

2. Check and refresh credentials. Navigate to Integrations → [integration name] → Edit Credentials. If you are using an API key or token, verify it is still valid by testing it directly against the source system's API. If it has expired or been rotated, generate a new key in the source system and update it in CMDash. Click Save and Test to confirm the new credential works.

3. Check firewall and IP allowlisting. If your environment restricts outbound HTTPS or your source system restricts inbound API calls by IP, ensure CMDash's IP ranges are allowlisted. See www.cmdash.com/docs/ip-ranges — the SaaS has no fixed egress IP list; that page explains the collector and self-hosted options that give you one. This is most common for on-premises deployments of tools like Nessus or internal Jira instances.

4. Check API rate limits. Some source systems (notably CrowdStrike and Tenable) enforce API rate limits. If you recently triggered multiple manual syncs or the source system has many active API clients, CMDash may have been rate-limited. Wait 15 minutes, then click Sync Now to retry.

5. Review the sync error log. Navigate to Integrations → [integration name] → Sync Logs and review the most recent error messages. Error codes and descriptions are shown in the log and often point directly to the cause (e.g., "401 Unauthorized" = credential issue; "429 Too Many Requests" = rate limit).

If the issue persists after completing all steps, contact support by email and include: the integration name, the error message from the sync log, and your organization name and account email.

No data after connecting an integration

Symptom: An integration shows as "Healthy" but no data appears in the dashboard or compliance views.

Likely causes:

• The initial sync has not completed yet.
• The source system has no data to sync (e.g., no scans have been run).
• The API credentials are scoped to the wrong tenant, site, or organization within the source system.

Resolution steps:

1. Wait for the first sync to complete. Navigate to Integrations → [integration name] and check the Last Synced timestamp. If it shows "Never" or a timestamp from the last few minutes, the initial sync may still be in progress. Initial syncs can take up to 30 minutes for systems with large data sets (e.g., Tenable with years of scan history). Do not disconnect and reconnect the integration — this resets the sync.

2. Confirm data exists in the source system. Some integrations require data to be present before CMDash can pull it:

   • Tenable: At least one completed scan must exist. If Tenable has never run a scan, there are no vulnerabilities for CMDash to import.
   • CrowdStrike: Sensors must be deployed to at least one endpoint.
   • Proofpoint: Email data requires at least 24 hours of telemetry to generate meaningful metrics.

3. Verify the integration scope. Navigate to Integrations → [integration name] → Configuration and confirm the integration is pointed at the correct tenant, site, organization, or account within the source system. For multi-tenant source systems, using the wrong tenant ID is a common cause of a healthy connection with no data.

4. Trigger a manual sync and wait for it to complete. Then reload the dashboard.

If the integration has been connected for more than 60 minutes, shows "Healthy," and the source system definitely has data, contact support with the integration name and tenant ID.

Integration keeps disconnecting

Symptom: An integration repeatedly goes to "Unhealthy" or "Disconnected" status, requiring you to re-enter credentials to restore it.

Likely cause: The API token or OAuth access token used by the integration has an expiry date and is being revoked or expired on a recurring schedule.

Resolution steps:

1. Identify the token expiry policy in the source system. Some systems enforce short-lived tokens:

   • SentinelOne: API tokens have a configurable expiry (commonly 30, 60, or 90 days). Note the expiry date when generating the token.
   • CrowdStrike: API credentials do not expire, but can be revoked by an admin.
   • Okta: Service tokens can be scoped to expire; use a long-lived or non-expiring service account token for CMDash.

2. Generate a non-expiring or long-lived API token in the source system if supported, and update the CMDash integration credentials.

3. Set a calendar reminder for the expiry date of any token that cannot be made non-expiring, and rotate the credential in CMDash before it expires.

4. Check for automated credential rotation policies in your organization that may be rotating the API key or service account password used by CMDash without your knowledge.

You can configure integration health alerts (Notification Channels, in the main nav, plus a matching alert rule under Alert Rules) to receive email, Slack, Teams, or webhook notifications when an integration goes unhealthy, providing advance warning before data goes stale. This is available on every plan, not just Enterprise.

Wrong data showing for an integration

Symptom: An integration is healthy and syncing, but the data shown in CMDash doesn't match what you see in the source system.

Likely causes:

• The integration credentials are scoped to the wrong organizational unit, site, or tenant within the source system.
• The API credentials lack the permission scope to read all required data types, causing partial results.
• A data normalization issue specific to your configuration.

Resolution steps:

1. Verify the credential scope and permissions in the source system. Log in to the source system and check what data the API user or service account can access. If the service account only has access to a subset of assets, endpoints, or scan targets, CMDash will only see that subset.

2. Check tenant/site/organization alignment. For source systems that are multi-tenant or multi-site (CrowdStrike, Tenable), navigate to Integrations → [integration name] → Configuration and confirm the configured tenant ID, site ID, or organization name matches the production environment you intend to connect. It is common to accidentally connect to a staging or sandbox instance.

3. Review the required API scopes. Navigate to Integrations → [integration name] → Required Permissions in the CMDash documentation to confirm the credentials include all required read scopes. A common issue is that credentials can read host data but cannot read vulnerability findings, resulting in accurate endpoint counts but missing vulnerability data.

4. Trigger a manual sync after correcting any scope or configuration issues.

If the data still doesn't match after verifying scope and permissions, contact support with specific examples of the discrepancy (e.g., "Tenable shows 847 high-severity findings; CMDash shows 312").

Compliance & Controls

Control shows "Not Met" but evidence exists

Symptom: A compliance control shows a "Not Met" status in CMDash, but you have implemented the control and the evidence exists.

Likely causes:

• The integration providing automated evidence for this control is not connected or is unhealthy.
• Manually uploaded evidence has expired.
• The evidence timestamp falls outside the required date range for the control.
• The control requires manual attestation and no attestation has been recorded.

Resolution steps:

1. Check which evidence sources are required. Navigate to Compliance → [Framework] → [Control] → Evidence. CMDash shows which integrations are mapped to this control and whether they are providing passing data. If a required integration is not connected, that integration's contribution to the control is absent.

2. Check the status of connected integrations. If the required integration is connected but unhealthy, no evidence is flowing from it. Resolve the integration issue first (see Integration shows "Unhealthy" or "Error").

3. Check manual evidence expiry. If you previously uploaded manual evidence (a policy document, screenshot, or attestation), navigate to the control's evidence panel and check the Valid Until date. Expired evidence does not count toward a "Met" status. Re-upload or re-attest the evidence with a current date.

4. Check the evidence date range. Some frameworks require that evidence be dated within a specific window (e.g., within the last 12 months for SOC 2, within the last 6 months for some CMMC controls). Even if evidence exists, if it is dated outside the required window, the control will show "Not Met."

5. Add a manual attestation. For controls that cannot be satisfied through automated integrations (physical security controls, contractual obligations, personnel training), navigate to Compliance → [Framework] → [Control] → Add Evidence → Manual Attestation and complete the attestation form.

Framework completion percentage dropped suddenly

Symptom: Your compliance framework completion percentage decreased noticeably without you making changes.

Likely causes:

• A control that was previously "Met" has regressed because evidence became stale, an integration went unhealthy, or a new vulnerability was discovered.
• An integration's credential expired, causing automated evidence for multiple controls to become invalid.

Resolution steps:

1. Identify the regressed controls. Navigate to Compliance → [Framework] and sort controls by Status Changed (Recent) to see which controls recently moved from "Met" to "Not Met" or "In Progress."

2. Inspect each regressed control. Click each affected control and review the Evidence tab to understand why the status changed. Common causes include:

   • An integration last-synced timestamp that is old (indicating a sync failure)
   • An evidence file with an expired Valid Until date
   • A new vulnerability finding that violates the control

3. Resolve the root cause. If an integration is failing, see Integration shows "Unhealthy" or "Error". If evidence has expired, re-upload it. If a new vulnerability is the cause, address the vulnerability in the source system and allow the next sync to update the control status.

CMMC controls not appearing

Symptom: CMMC controls are not visible under the Compliance section.

Likely cause: CMMC Level 1, 2, or 3 is toggled out of scope. CMMC tracking is available on every plan — it is not gated by tier.

Resolution steps:

1. Add the CMMC level to your scope. Navigate to Compliance → Manage scope and toggle on CMMC Level 1, CMMC Level 2, and/or CMMC Level 3 (each level is tracked as its own framework, not a dropdown choice). If a level isn't listed, contact support.

2. Set your target level. Separately, the CMMC Level tab on Security Program (Security → All Security tools → Security Program → CMMC Level, route /program/cmmc-level) lets you record which level your program is actually pursuing — this drives the self-assessment export, audit package, and SPRS score elsewhere in CMDash, but it doesn't by itself add controls to the Compliance section; you still need step 1.

3. Allow up to 5 minutes for the framework to initialize and controls to populate after adding it to scope. Refresh the Compliance page.

POA&M export is missing some risks

Symptom: The exported POA&M file is missing risks that you can see in the Risk Register.

Explanation: This is by design. The POA&M export is specifically formatted for CMMC and FedRAMP compliance submissions and only includes risks that meet all of the following criteria:

• Status is Open or In Remediation (not Accepted or Closed)
• The risk is linked to at least one CMMC or FedRAMP control in the compliance module
• The risk has a due date assigned

Resolution steps:

1. Check the risk's status. Risks with status "Accepted" or "Closed" are intentionally excluded from the POA&M, as they do not represent open action items.

2. Check the risk's control linkage. Navigate to Risk Register → [risk] → Linked Controls and verify the risk is linked to at least one CMMC or FedRAMP control. If it is not, add the linkage.

3. Check that a due date is assigned. Risks without due dates are excluded from the POA&M because the POA&M format requires milestone dates.

4. For a broader risk export that includes all risks regardless of framework linkage or status, use the Export CSV button on the Risk Register instead.

User & Access Issues

User says they can't see a feature

Symptom: A user reports that a feature, menu item, or page is missing or inaccessible.

Likely causes:

• The user's role (Viewer) does not include access to that feature.
• The feature requires a higher-tier plan.
• The feature is behind a feature flag that is being gradually rolled out.

Resolution steps:

1. Check the user's role. Navigate to Members and review their assigned role. Viewers cannot access Settings, cannot edit the Risk Register, cannot manage integrations, and cannot invite other users. If the user needs write access, change their role to Admin (Owner only).

2. Check plan-level feature availability. Some features are exclusive to higher tiers:

   • White-label branding: Command+
   • SCIM provisioning: Enterprise
   • SSO / SAML 2.0: Starter+ (moved down from Enterprise)
   • LDAP directory sync: Enterprise
   • vCISO multi-client console: Command+
   • FAIR risk quantification: Starter+ (moved down from Enterprise)

   Custom signal weights, custom roles, and CMMC tracking are available on every plan — they are not tier-gated.

   Navigate to Settings → Billing to see your current plan and compare with www.cmdash.com/pricing.

3. Check for feature flags. Some features are rolled out incrementally and may not be available to all tenants simultaneously. If you believe a feature should be available on your plan but it's not appearing, contact support to confirm availability for your tenant.

Invitation email not received

Symptom: A user you invited reports not receiving the CMDash invitation email.

Resolution steps:

1. Ask the user to check their spam or junk folder. Invitation emails come from hello@cmdash.com. If the user's email security gateway is filtering CMDash emails, the message may be quarantined.

2. Revoke and re-send the invitation. Navigate to Members, click Revoke on the pending invitation, then send a new invite to the same address. There is no separate "resend" action — revoking and re-inviting issues a fresh link.

3. Allowlist CMDash's sending domain. If the user's organization is filtering emails from cmdash.com or hello@cmdash.com, have their IT team add hello@cmdash.com and the domain mail.cmdash.com to the email allowlist (sometimes called a "safe senders" list).

4. Verify the email address is correct. Navigate to Members and confirm the invited email address has no typos. If it is wrong, revoke the incorrect invitation and send a new one to the correct address.

SSO login failing

Symptom: Users are unable to log in via Single Sign-On (SAML/SSO). This feature is available starting on the Starter plan.

Likely causes:

• The IdP (identity provider) configuration (Entity ID, SSO URL, or signing certificate) has changed or expired in CMDash.
• The user's IdP account is inactive or not assigned to the CMDash application.

Resolution steps:

1. Re-check the SAML configuration. Navigate to Settings → SSO and verify the Entity ID, SSO URL, and signing certificate still match what your IdP issues. If your IdP recently rotated its signing certificate, paste the new certificate in here and save.

2. Verify the user is active and assigned in the IdP. Log in to your IdP admin console and confirm the affected user's account is active and that the user is assigned to the CMDash application.

3. Check group mapping if roles look wrong. Settings → SSO has an optional Group Mapping field (JSON) that maps IdP group names to CMDash roles. If a user is logging in but landing with the wrong role, verify their IdP groups are covered by this mapping — unmapped users fall back to the configured default role.

4. Use a password-based login to regain access while debugging. If SSO is broken and no one can sign in, an account with a password set (typically the Owner, if one was created before SSO was enabled) can still sign in normally at /login with email and password — CMDash does not require a special bypass parameter.

5. Contact support. Share the exact SAML error page or message with support@cmdash.com for faster diagnosis.

SCIM sync not deprovisioning users

Symptom: After removing a user from your IdP or deactivating their account, the user still appears as active in CMDash. This feature is available on Enterprise plan.

Likely causes:

• The SCIM token used to connect your IdP to CMDash has expired.
• The user was removed from the CMDash application group in the IdP but their account was not deactivated in the IdP.
• A SCIM sync cycle has not occurred since the change.

Resolution steps:

1. Check the SCIM token. SCIM is enabled from the SCIM Provisioning section of Settings → SSO (SCIM is part of the same page as SAML SSO, not a separate settings area). If provisioning has stopped working, generate a new SCIM token there and update it in your IdP's SCIM provisioning configuration — the token is shown only once, at generation time.

2. Confirm the user is deactivated in the IdP — not just removed from a group. SCIM deprovisioning in CMDash triggers when the IdP sends a SCIM PATCH or DELETE request for the user. Most IdPs only send this request when the user account itself is deactivated, not when they are simply removed from an application assignment or group. In Okta, for example, you must deactivate the user's Okta account (or use lifecycle management rules) to trigger deprovisioning. Removing the user from the CMDash app assignment alone may not trigger a SCIM event in all IdPs.

3. Narrow the user's custom role to no access, as an immediate measure, from Roles, while you investigate the SCIM configuration — CMDash does not currently offer a self-service "deactivate this member" action, so restricting their role is the fastest interim mitigation.

4. Contact support with the affected user's email and your IdP name if the SCIM token is current and the IdP shows the account as deactivated, but CMDash still shows the user as active — support can deactivate the account directly.

Reports & Exports

Board PDF is blank or missing data

Symptom: The board report PDF opens but shows blank sections, missing charts, or placeholder text.

Likely causes:

• No integration has completed a sync, so there is no posture data to render.
• The browser is blocking the popup or the PDF generation tab.

Resolution steps:

1. Verify at least one integration has synced. Navigate to Integrations and confirm that at least one integration shows a recent Last Synced timestamp (not "Never"). If no integrations have synced, posture data is unavailable and the report will be empty.

2. Check browser popup settings. The board PDF opens in a new tab. If your browser is configured to block popups, the new tab may open blank. Allow popups from app.cmdash.net in your browser settings and try generating the report again.

3. Clear browser cache and retry. Navigate to your browser's settings, clear the cache and cookies for app.cmdash.net, then reload and regenerate the report.

4. Try a different browser. If the issue is browser-specific, try Chrome or Edge. Firefox's PDF rendering occasionally has compatibility issues with dynamically generated PDFs.

Board deck .pptx won't generate

Symptom: Clicking "Download .pptx" either results in an error message or the download never starts.

Likely causes:

• The PowerPoint file is still being generated (large tenants with extensive evidence packages can take up to 2 minutes).
• A transient server-side error occurred during generation.

Resolution steps:

1. Wait and retry. If you clicked Download and nothing happened, wait 2 full minutes and click again. The generation process runs server-side and may still be in progress.

2. Check the CMDash status page. Visit www.cmdash.com/status to confirm there are no active incidents affecting report generation.

3. Try the PDF version instead. If the .pptx is not generating, try generating the PDF board report as an alternative while the issue is investigated.

4. Contact support. If the issue persists after 5 minutes, contact support by email and provide: your organization name and account email, the approximate time you attempted the download, and the browser you are using.

Scheduled report not received

Symptom: A scheduled report was expected (daily, weekly, or monthly) but the email was not received.

Resolution steps:

1. Check the email spam folder. Scheduled reports are sent from reports@cmdash.com. If this domain is not in your allowlist, the email may be filtered.

2. Verify the recipient list on the scheduled report itself. Scheduled reports have their own Recipients field (comma-separated emails) set when the report is created — they do not use the separate Notification Channels feature. Navigate to Settings → Reports and check the recipient list on the affected report for typos or an out-of-date address.

3. Verify the scheduled report is still active. Navigate to Settings → Reports and confirm the schedule you set up shows Active (not Paused) status. Schedules can be accidentally paused or deleted.

4. Confirm the schedule settings. Review the configured cadence, day, and hour (reports are scheduled in UTC). A report scheduled for a given UTC hour will arrive at different wall-clock times depending on the recipient's time zone.

Performance

Dashboard loads slowly

Symptom: The CMDash dashboard takes more than 10 seconds to load, or tiles spin indefinitely.

Resolution steps:

1. Clear your browser cache. In Chrome: Settings → Privacy and Security → Clear browsing data → Cached images and files. Retry after clearing.

2. Try a different browser or private/incognito window. Browser extensions (ad blockers, security tools) can interfere with dashboard loading.

3. Check the CMDash status page. Visit www.cmdash.com/status to see if there is an active performance incident.

4. Check your network connection. A slow or intermittent connection can cause dashboard timeouts. Test your connection speed at fast.com and try a different network if possible.

5. Report to support. If the problem persists across browsers and networks, contact support with: your browser name and version, operating system, and the approximate time the slowness began.

Large Risk Register is slow to load

Symptom: The Risk Register page loads slowly or times out when you have a large number of risks (typically 500+).

Resolution steps:

1. Use Saved Views with filters. On the Risk Register, filter the list, then use the Saved views menu → Save current to save a filtered view that limits the displayed risks to a specific status, owner, business unit, or tag. Loading a filtered view is significantly faster than loading all risks.

2. Use the CSV export for bulk analysis. If you need to work with the full risk dataset (sorting, pivoting, bulk edits), export it via the Export CSV button on the Risk Register and analyze it in Excel or Google Sheets. CMDash's CSV export is optimized for bulk data and does not have the page-load limitations of the UI.

3. Filter out closed risks. CMDash does not have a separate archive for closed risks — select all "Closed" risks (using the status filter) and save that exclusion as a Saved View instead, so your default working view stays fast without needing a bulk-delete step.

Where to Get More Help

If you've worked through the relevant troubleshooting steps and the issue is still unresolved:

Opening a support ticket

Open Support in the dashboard (or press ? on any page and follow the link) and click New ticket. Give it a one-line summary, describe what you were doing and what happened instead, and pick a priority — priority helps us triage, but it does not change the commitment your plan carries.

Every ticket starts a first-response clock the moment you open it, taken from your plan's published commitment on the pricing page and defined on the SLA page — 2 business days on Starter, 1 business day on Essentials, 8 business hours on Command, and 4 calendar hours on Enterprise. Business hours are 09:00–18:00 US Eastern, Monday to Friday, so a ticket opened at 17:00 on a Friday resumes its clock at 09:00 on Monday. Enterprise's commitment is stated without the word "business" because it runs on calendar hours and does not pause overnight or at the weekend.

The ticket page shows that commitment, when a reply is due, and — if we go past it without answering — says so, in the same place, to you. First response is time to an initial human reply, not time to a fix.

Replying by email works. Every notification we send about a ticket carries a [CMDash #1a2b3c4d] tag in the subject; reply to it from the address you sign in with, keep the tag in the subject, and your reply lands on the same thread. A reply from an address that is not a member of your organization is ignored rather than added, so forwarding a ticket email to a colleague who does not have a CMDash account will not get them onto the thread — invite them instead.

Closing a ticket is yours to do at any time from the thread. Replying to a closed ticket reopens it; it does not restart the first-response clock, which is about the first answer to the first question.

When contacting support, please include:

• Your organization name and the account email you sign in with
• The integration name (if applicable)
• The exact error message or symptom
• The time the issue first occurred
• What troubleshooting steps you have already tried