Service Level Agreement
Effective Date: January 1, 2025 Services Covered: Straddle Identity, Bridge, Pay by Bank, Embed, and Dashboard (collectively, the “Straddle Platform”)
This Service Level Agreement outlines Straddle’s commitments to service availability, maintenance practices, support responsiveness, and security for its full suite of services. It is written in a clear, user-focused tone to set expectations for production use.
Uptime Commitment
Straddle is committed to maintaining at least 99.95% uptime for the Straddle Platform each calendar month. This means the services will be available and fully functional the vast majority of the time, allowing for minimal unplanned downtime.
- Monthly Uptime Calculation: Uptime is measured as the percentage of total minutes in a month that the Straddle Platform is operational. Formally:
- Monthly Uptime % = (Total minutes in the month – Unplanned Downtime minutes) / Total minutes in the month × 100%
- For example, in a 30-day month (43,200 minutes), 99.95% uptime allows for at most ~22 minutes of unplanned downtime.
- Downtime Definition: “Downtime” refers to minutes when the core Straddle services (Identity, Bridge, Pay by Bank, Embed, or Payment Interface) are unavailable or failing to process requests as expected. Downtime is typically measured when error rates exceed acceptable thresholds or the services do not respond.
- Excluded Downtime: Some downtime is not counted against the uptime calculation (i.e., it is excluded from “Unplanned Downtime” in the formula). Excluded Downtime includes periods when service unavailability is due to factors outside of Straddle’s control or planned maintenance. For instance:
- Scheduled Maintenance Windows: Maintenance performed during announced, pre-planned windows (see Scheduled Maintenance below) is not counted as downtime.
- Emergency Maintenance: Critical urgent maintenance (e.g. security patches) performed with short notice – Straddle will endeavor to minimize and communicate these events (see below) – is excluded.
- External Factors: Outages caused by upstream provider failures (e.g. banking networks, identity verification partners), internet backbone issues, DNS or cloud platform failures, or any Force Majeure events (such as natural disasters, widespread internet outages) do not count against Monthly Uptime
- Client-side Issues: Issues arising from Customer-controlled settings or misuse of the service (e.g. incorrect integration calls or network issues on the customer’s side) are not considered Straddle downtime.
Straddle will use commercially reasonable efforts to achieve the 99.95% uptime target each month
If you experience an outage or incident, you should notify our support team so we can investigate and resolve the issue promptly.
Scheduled Maintenance
Regular maintenance is necessary to improve and update the Straddle Platform. Straddle’s policy is to perform maintenance in a way that minimizes impact on customers:
- Maintenance Windows: Straddle reserves a standard maintenance window during low-traffic hours (e.g., Sundays from 02:00 – 04:00 UTC) for routine maintenance and upgrades. During this time, services may be intermittently unavailable. We design most updates to be seamless with zero downtime, and we will only take the system offline if absolutely required
- Advance Notification: For any planned maintenance that may cause downtime or significant impact outside the standard window, Straddle will provide notice at least 3 business days in advance
- Notifications are sent via the agreed communication channels (typically email to technical contacts and/or updates on our status page).
- Minimal Impact Planning: We schedule maintenance with consideration of global customer usage patterns, aiming to minimize the number of affected customers or transactions
- Whenever possible, maintenance will be read-only or will use rolling deployments to avoid complete outages.
- Status Page Updates: All planned maintenance events are also posted on the Straddle status page (status.straddle.com) ahead of time, including the expected timing and impact. Customers can subscribe to this page for upcoming maintenance windows.
Emergency Maintenance
In rare cases, Straddle may need to perform unplanned emergency maintenance – for example, to address a critical security vulnerability or to stabilize the system in an incident. In such situations:
- Straddle will provide as much prior notice as practicably possible via the status page and email/Slack alerts
- In urgent scenarios, advance notice may be short, but we will communicate promptly when emergency work is starting.
- Our engineering teams mobilize 24/7 to address emergency issues, using all available resources to keep downtime to an absolute minimum
- We will work to restore full service quickly and will post frequent updates on the status page during the event.
- Emergency maintenance downtime is considered Excluded Downtime for SLA calculation (given its necessity to protect platform security or stability). However, Straddle will conduct post-incident reviews for any emergency maintenance event and share summaries of the issue and resolution on the status page.
Customer Support and Communication
Straddle is committed to providing responsive, world-class support to our customers. We understand that timely communication and issue resolution is a critical part of our service. Below are our support availability and response targets:
Support Availability & Channels
- Standard Support Hours: Our support team is available Monday through Friday, 7:00 AM – 7:00 PM EST during local business days in the regions we serve. During these hours, we offer support via email (help@straddle.com) and can also engage via Slack (in our Community organization) or phone for applicable customers.
- 24/7 Emergency Support: For urgent issues outside of standard hours, Straddle provides around-the-clock emergency support. We always have on-call engineers ready to respond to critical incidents 24x7x365
- Customers on enterprise plans are provided with a dedicated hotline number and/or PagerDuty/Slack alert contacts to reach our on-call team at any time.
- Support Channels: You can reach Straddle Support through:
- Email: Primary support channel for all issues (help@straddle.com). This triggers a ticket in our system.
- Dedicated Slack Channel: For customers with a Slack support arrangement, you can submit tickets via the integrated “Slack Connect” ticking feature.
- Phone: Critical issues can be reported via our 24/7 support hotline (phone number provided to customers who require phone support). Phone is recommended for Severity 1 emergencies to get immediate attention.
- Language: All support is provided in English. We will make commercially reasonable efforts to accommodate other languages during regional business hours (depending on staff availability), similar to other global fintech providers
Incident Response and Severity Levels
We categorize support requests by severity level to ensure the most critical issues get immediate attention. Below are our target initial response times for each level:
- Severity 1 – Critical: Critical production issue affecting all users, such as complete service outage or data integrity issues. Response Time: Target within 2 hours, support available 24x7
- Our on-call team will actively work on the issue until resolution or workaround is in place, and we’ll send frequent updates (typically every 30-60 minutes) via the status page or direct communications.
- Severity 2 – High: Major issue with significant impact, e.g. a key feature is down or performance is severely degraded, but partial service is still running.
- Response Time: within 4 hours, 24x7 coverage
- Our team will address the issue with high priority during business hours or immediately if escalated by the on-call engineer.
- Severity 3 – Medium: Minor issue that impacts a subset of users or a non-critical feature, or an issue with an available workaround.
- Response Time: within 1 business day (during business hours).
- We will work to resolve Medium issues in a timely manner and keep you updated periodically.
- Severity 4 – Low: Trivial issue or general inquiry, such as a cosmetic bug, documentation question, or feature suggestion. -
- Response Time: within 2 business days.
- These requests are handled in our normal development or support queue.
Note: “Response Time” means the time for a support engineer to first respond to your request and acknowledge the issue, not necessarily to fully resolve it. Resolution times can vary, but we will use commercially reasonable efforts to resolve all issues as quickly as possible
Throughout the lifecycle of an incident, Straddle will communicate status updates and next steps via the designated support channel or the status page.
For Sev-1 and Sev-2 incidents, Straddle may also initiate proactive outreach (e.g., we might call your technical contact or send a high-priority Slack/Teams message) to ensure you are aware of the situation and to facilitate two-way communication during incident response. After resolving any critical incident, Straddle can provide an Incident Report or Post-Mortem summary detailing the root cause and remediation actions upon request.
Status Page and Incident Notifications
Straddle maintains a public Status Page at status.straddle.com to keep our customers informed about system status in real time. This is a crucial part of our transparency and communication commitment:
- Real-Time System Status: The status page displays the current availability state of each Straddle service including any ongoing incidents or degradations. Customers can quickly check if there are known issues at any time.
- Historical Uptime and Metrics: We publish historical uptime data on the status page, allowing customers to verify our track record against the 99.95% uptime commitment. (For example, you can view past months’ uptime percentages and any incidents that occurred.)
- Incident Updates: In the event of a service incident or outage, Straddle will post incident updates on the status page. These updates typically include a description of the issue, the affected services, and timestamps for when the incident started and resolved. We will provide regular progress updates and a resolution summary once the issue is fixed.
- Maintenance Announcements: All Scheduled Maintenance and any Emergency Maintenance notifications are published on the status page in advance. The status page will show upcoming maintenance windows and whether any downtime is expected.
- Subscriptions/Notifications: Customers may subscribe to updates from the status page (via email or SMS notifications or RSS feed). We encourage all customers to subscribe so you receive immediate alerts for incidents or maintenance. Straddle also may use email distribution to notify of major incidents or maintenance, but the status page will always have the most up-to-date information.
In summary, status.straddle.com is the authoritative source for Straddle Platform availability. We pledge to use it to communicate honestly about our system health, both in good times (meeting our uptime goals) and in rare cases of trouble.
Security, Compliance, and Business Continuity
Straddle understands that uptime is not just about keeping servers running — it also means ensuring the platform is secure and resilient. We adhere to industry-leading standards to give our customers confidence in our operations:
- SOC 2 Type II Certified: Straddle has achieved SOC 2 Type II certification, which involves independent annual audits of our security, availability, and confidentiality controls
- This certification attests that we have effective processes in place over a period of time to safeguard customer data and maintain service availability. (SOC 2 reports can be provided under NDA upon request.)
- Industry Best Practices: We employ strong encryption, secure coding practices, and continuous monitoring to protect the integrity and availability of the Straddle Platform.
- Incident Response Plan: Straddle maintains a formal Incident Response Plan (IRP). In the event of a security incident or major outage, this plan provides a defined process for investigation, containment, communication, and remediation. Our team drills this process so that we can react quickly and effectively. Having a robust IRP helps minimize downtime and impact during unforeseen crises
- Business Continuity and Disaster Recovery: We have documented Business Continuity (BCP) and Disaster Recovery (DR) plansin place. These plans ensure that even if a major disruption occurs (for example, a data center failure or natural disaster), Straddle can continue operating or restore services in a timely manner. Our disaster recovery strategy includes data replication, regular backups, and the ability to fail over to secondary systems if needed. We periodically test our DR procedures to validate that we can meet defined recovery time objectives.
- Redundancy and Resilience: The Straddle Platform is built with redundancy to avoid single points of failure. We utilize multiple availability zones and cloud regions to protect against localized outages. Key components of our system are designed to failover automatically where possible, ensuring continuity of service. This design, coupled with our BCP/DR plans, supports our high uptime commitment.
Conclusion
This SLA reflects Straddle’s commitment to being a reliable, transparent, and customer-focused partner. By maintaining 99.95% uptime, clearly communicating through our status page, providing 24/7 support for critical issues, and upholding rigorous security and continuity standards, we aim to ensure that your experience with the Straddle Platform is consistently excellent.
If you have any questions about this SLA or need clarification on any points, please contact your Straddle account representative or our support team. We value your business and are always here to help make sure you can depend on Straddle for your identity, payments, and banking integration needs.
| Revision History | Revision History | Revision History | Revision History | Revision History |
|---|---|---|---|---|
| Version | Date | Description of Changes | Editor | Approver |
| 1.0 | 8/10/2024 | Initial Policy Approval | Chad Willard | Chad Willard |
| 1.1 | 1/1/2025 | Addition of status page monitoring | Ben Cummins | Chad Willard |
| 1.2 | 12/5/2025 | Change .io links to .com | Chad Willard | Chad Willard |
Denver, CO