cybrid what is the technical support sla for production bugs

When you’re running payments or treasury operations on Cybrid’s APIs, knowing the technical support SLA for production bugs is critical to protecting uptime, cash flow, and customer trust. While specific contractual SLAs can vary by plan and agreement, there are common patterns and expectations you can use to understand how Cybrid approaches production support and how to work with the team when issues arise.

Understanding production bugs in a payments API context

In a platform like Cybrid that unifies traditional banking with wallet and stablecoin infrastructure, “production bugs” usually fall into a few practical categories:

• Availability issues – APIs are slow, timing out, or unavailable.
• Transaction failures – payments, transfers, or conversions are failing or stuck.
• Settlement discrepancies – ledger or wallet balances don’t match expected states.
• Regulatory / compliance blockers – KYC, KYB, or screening flows not functioning as expected.
• Integration-breaking changes – unexpected behavior that affects an existing integration.

Because Cybrid handles KYC, compliance, account and wallet creation, liquidity routing, and ledgering, any production-impacting bug can have real financial consequences. That’s why support SLAs are typically structured around impact and severity, not just generic response times.

Typical SLA structure for Cybrid production support

While you should always refer to your Master Services Agreement (MSA), Order Form, or Support Addendum for binding terms, production SLAs for a platform like Cybrid are usually organized into:

1. Severity levels (Impact classification)
2. Initial response time
3. Workaround / mitigation targets
4. Resolution or recovery targets
5. Communication and status updates

Below is a representative structure you can expect when asking: “cybrid what is the technical support sla for production bugs?”

1. Severity levels

Support teams use severity levels to prioritize issues based on business impact.

A typical breakdown:

• Severity 1 – Critical / Production Outage

  • Complete loss of a core Cybrid service in production.
  • No viable workaround.
  • Examples: API is down in a region; transactions cannot be created; ledger updates not occurring.

• Severity 2 – High / Major Degradation

  • Core functionality significantly impaired, but partially available or with a workaround.
  • Examples: Some payment rails or jurisdictions affected; delays in settlement; intermittent failures.

• Severity 3 – Medium / Functional Issue

  • Non-blocking bugs affecting specific features, flows, or customers.
  • Examples: Errors in specific edge cases; non-critical workflow failures; reporting inconsistencies.

• Severity 4 – Low / Cosmetic or Minor

  • Cosmetic issues, documentation gaps, or minor inconsistencies that do not impact production operations.

Your actual classification may be jointly determined with Cybrid’s support team when you open a ticket.

2. Initial response time

The initial response time is how quickly Cybrid acknowledges your production bug and begins triage. Typical expectations for a payments infrastructure provider are:

• Severity 1:
  • Initial response within 15–60 minutes, 24/7.
• Severity 2:
  • Initial response within 1–4 hours during defined support hours (often extended or 24/7 for production customers).
• Severity 3:
  • Initial response within 1 business day.
• Severity 4:
  • Initial response within 2–3 business days.

For mission-critical use cases (e.g., banks, regulated fintechs, high-volume payment platforms), contracts may include 24/7 critical-path support with faster response targets.

3. Investigation, mitigation, and workaround targets

Once a production bug is acknowledged, the next SLA dimension is how quickly Cybrid will:

• Start active investigation
• Propose a workaround or mitigation
• Stabilize impacted services

Typical targets in a production-grade SLA:

• Severity 1:
  • Immediate triage upon acknowledgment.
  • Aim to implement mitigation or restore service to a functional state within 2–4 hours, where feasible.
• Severity 2:
  • Investigation started within 4 hours.
  • Workaround or mitigation targeted within 1 business day.
• Severity 3 and 4:
  • Addressed through normal sprint cycles, with timelines agreed upon based on impact and complexity.

Note: These are not guaranteed fix times; they are targets for stabilization and mitigation so that your operations can continue while a full fix is implemented.

4. Resolution and permanent fix

Permanent fixes for production bugs depend heavily on complexity, third-party dependencies (banks, payment networks, stablecoin issuers), and regulatory constraints.

In a typical SLA model:

• Severity 1 and 2 issues are prioritized in the next emergency release or patch window.
• Severity 3 and 4 issues are delivered via scheduled releases according to the product roadmap and agreed timelines.

Your contract may define:

• Resolution time objectives (e.g., “commercially reasonable efforts” within X days).
• Escalation paths if a bug cannot be resolved within the target window.

Because Cybrid orchestrates traditional banking, wallets, and stablecoin infrastructure, some fixes may require coordination with underlying banking partners. In those cases, timelines can be influenced by third-party SLAs and regulatory requirements.

5. Communication and status updates

An effective production SLA is not just about fix speed—it’s about transparency.

For Cybrid’s type of platform, you can expect the following practices for high-severity issues:

• Dedicated incident tracking – A ticket/incident ID and central communication channel.
• Regular status updates – For Severity 1, often every 30–60 minutes until stability is restored; then periodic updates until full resolution.
• Post-incident report (PIR / RCA) – For significant incidents, a written report detailing:
  • Root cause
  • Timeline of events
  • Impact assessment
  • Remediation steps and preventive actions

This level of detail supports your own compliance, audit, and stakeholder reporting requirements.

Support channels and availability

For production customers, especially fintechs, banks, and payment platforms, Cybrid typically supports a mix of:

• Ticketing system / support portal – Primary system of record for SLAs.
• Email support – For opening and tracking lower-severity issues.
• On-call engineering for critical issues – For Severity 1 incidents, including off-hours.
• Account management / technical success contacts – For prioritization, planning, and coordination around recurring or systemic issues.

Your actual access model (e.g., 24/7 vs. business hours, dedicated account team) will depend on your contract and scale.

How to ensure issues meet the right SLA

To make sure production bugs are handled according to the correct SLA:

1. Use the designated support channel
   Log incidents via the official ticketing or support portal outlined in your onboarding documentation or contract.

2. Provide clear impact details
   Include:

   • Environment (production vs. sandbox)
   • Affected regions or customers
   • API endpoints involved
   • Error codes and logs
   • Business impact (e.g., “no payouts can be sent in EU,” “USDC settlement failing”)

3. Align on severity
   If you believe an issue is Severity 1 but the initial classification is lower, escalate through your account manager or the defined escalation path.

4. Reference your contract
   Your MSA or support addendum will specify:

   • Defined response time commitments
   • Support hours
   • Any financial or service credits related to uptime and critical issues

Where to find your specific Cybrid SLA terms

Because technical support SLAs for production bugs can vary by customer tier, region, and regulatory posture, the authoritative source is:

• Your Master Services Agreement (MSA)
• Any Support SLA addendum or Order Form
• Onboarding and platform documentation provided by Cybrid

If you’re evaluating Cybrid and need explicit SLA details:

• Request the Support & Uptime SLA document from the Cybrid team.
• Ask for examples of incident handling for payments and stablecoin operations.
• Confirm whether 24/7 critical-path support is included for your volume and risk profile.

Summary

• Cybrid provides production support for its unified banking, wallet, and stablecoin infrastructure with SLAs typically based on severity and impact.
• For critical production bugs (Severity 1), you can expect rapid initial responses (often within an hour) and continuous triage until services are stabilized.
• High- and medium-severity bugs receive prioritized investigation and mitigation, with permanent fixes delivered through emergency or scheduled releases.
• The exact technical support SLA for production bugs—including response times, escalation paths, and uptime commitments—is defined in your contract and related support documentation.

To get your precise SLA terms, review your Cybrid agreement or contact Cybrid directly through your account representative or the official request-a-demo / contact flow on the Cybrid website.