ChargeOver Outage History

Started Aug 24, 2026, 09:18 PM UTC· resolved Aug 24, 2026, 09:55 PM UTC

1. investigating Aug 24, 2026, 09:18 PM UTC

   We are currently investigating this issue.

2. monitoring Aug 24, 2026, 09:34 PM UTC

   ChargeOver platform is stabilizing, and we are monitoring the situation closely. More updates to follow.

3. resolved Aug 24, 2026, 09:55 PM UTC

   This incident has been resolved. A postmortem will follow.

Read the full incident report →

Started Aug 01, 2026, 06:24 AM UTC· resolved Aug 01, 2026, 02:58 PM UTC

1. identified Aug 01, 2026, 06:24 AM UTC

   ChargeOver is currently inaccessible. We are working on a resolution ASAP.

2. monitoring Aug 01, 2026, 09:45 AM UTC

   ChargeOver service has been restored. Automated invoice generation, and automated payment processing is delayed, but will catch up rapidly and will not require any manual action by merchants. Sync of data to other platforms (QuickBooks, Xero, Salesforce) will be delayed, but will catch up rapidly, and will not require any manual re-sync. More updates and a postmortem will be posted later.

3. monitoring Aug 01, 2026, 09:46 AM UTC

   We are continuing to monitor for any further issues.

4. monitoring Aug 01, 2026, 10:44 AM UTC

   We are continuing to monitor for any further issues. Automated processes (creating invoices; running payments; syncing to QuickBooks/Xero/Salesforce) continue to catch up.

5. resolved Aug 01, 2026, 02:58 PM UTC

   This incident has been resolved, and all services are functioning normally now. A postmortem will follow.

Read the full incident report →

Started Apr 14, 2026, 04:46 AM UTC· resolved Apr 14, 2026, 12:45 PM UTC

1. investigating Apr 14, 2026, 04:46 AM UTC

   ChargeOver is currently unreachable. Our upstream network provider is experiencing an outage affecting connectivity to our data center. Our systems are online and operational; this is a network issue outside of our infrastructure. Our provider is aware of the issue and is actively working toward a resolution. We do not have an ETA at this time. We will post an update every 60 minutes until this is resolved.

2. investigating Apr 14, 2026, 05:58 AM UTC

   No change in status. Flexential has confirmed that carrier circuits at their Chaska, MN facility remain down. Their network engineers are engaged with the carrier vendor, who is actively investigating. No restoration ETA has been provided. Our systems remain online and operational. This continues to be a network connectivity issue upstream of our infrastructure. Next update in 60 minutes or sooner if status changes.

3. investigating Apr 14, 2026, 06:48 AM UTC

   Progress has been made in identifying the cause. Flexential's carrier vendor has isolated a faulty optical component on the affected circuit and a technician is en route to replace it. No restoration ETA has been provided yet. This continues to be a network connectivity issue upstream of our infrastructure. Next update in 60 minutes or sooner if status changes.

4. investigating Apr 14, 2026, 08:00 AM UTC

   No change in status. This continues to be a network connectivity issue upstream of our infrastructure. Next update in 60 minutes or sooner if status changes.

5. investigating Apr 14, 2026, 08:59 AM UTC

   ChargeOver is accessible again. Flexential has restored network connectivity to our data center and we are actively monitoring performance and stability. We have not yet received an official all-clear from Flexential. We will post a final update once we have confirmed full resolution.

6. monitoring Apr 14, 2026, 10:50 AM UTC

   We are continuing to monitor connectivity, and await an update from our primary data center (Flexential). ChargeOver is operating normally at this time. Some payments may need to be re-attempted. Some syncs to external platforms (QuickBooks, Xero, Salesforce, etc.) may be delayed or need re-sync.

7. resolved Apr 14, 2026, 12:45 PM UTC

   Connectivity issues have been resolved. Some payments may need to be re-attempted. Some syncs to external platforms (QuickBooks, Xero, Salesforce, etc.) may need re-sync.

Read the full incident report →

Started Mar 26, 2026, 04:57 PM UTC· resolved Mar 26, 2026, 05:18 PM UTC

1. investigating Mar 26, 2026, 04:57 PM UTC

   We are investigating the issue. We are expecting to have this resolved within the next 30 minutes.

2. resolved Mar 26, 2026, 05:18 PM UTC

   This has been resolved. We are investigating what occurred here still. A postmortem will follow.

Read the full incident report →

Started Dec 26, 2025, 10:57 PM UTC· resolved Dec 26, 2025, 11:29 PM UTC

1. investigating Dec 26, 2025, 10:57 PM UTC

   We are currently investigating this issue.

2. investigating Dec 26, 2025, 11:01 PM UTC

   We are continuing to investigate this issue.

3. monitoring Dec 26, 2025, 11:07 PM UTC

   A fix has been implemented and we are monitoring the results.

4. resolved Dec 26, 2025, 11:29 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Nov 11, 2025, 06:21 PM UTC· resolved Nov 11, 2025, 08:12 PM UTC

1. investigating Nov 11, 2025, 06:21 PM UTC

   We are currently investigating this issue. Some emails are not sending, instead triggering a "Invalid handle provided" message. Payment processing and integrations are unaffected.

2. identified Nov 11, 2025, 07:10 PM UTC

   We have identified the problem, and are expecting a resolution within the next 30 minutes. We will provide an update here again shortly.

3. monitoring Nov 11, 2025, 07:35 PM UTC

   This issue should be resolved now. We are monitoring this for any further action. A postmortem will follow.

4. monitoring Nov 11, 2025, 07:35 PM UTC

   We are continuing to monitor for any further issues.

5. resolved Nov 11, 2025, 08:12 PM UTC

   This incident has been resolved. A postmortem will follow.

Read the full incident report →

Started Oct 30, 2025, 01:41 PM UTC· resolved Oct 30, 2025, 07:34 PM UTC

1. identified Oct 30, 2025, 01:41 PM UTC

   We have identified a component failure which is delaying the sync of data to some systems for approximately 30% of ChargeOver accounts. The affected integrations are: * QuickBooks Online * Xero * Salesforce Syncing will catch up automatically, but may be delayed. We are still investigating root cause and will follow up with a postmortem.

2. monitoring Oct 30, 2025, 02:17 PM UTC

   Syncing has completely caught up for all but approximately 10% of ChargeOver accounts. The remaining ChargeOver accounts continue to catch up quickly, but are still delayed. We are continuing to monitor the situation, and a postmortem will follow.

3. resolved Oct 30, 2025, 07:34 PM UTC

   Syncing for all affected integrations is complete now. A postmortem will follow.

Read the full incident report →

Started Oct 28, 2025, 02:51 PM UTC· resolved Oct 28, 2025, 03:04 PM UTC

1. investigating Oct 28, 2025, 02:51 PM UTC

   ChargeOver is down for some users. We are investigating.

2. monitoring Oct 28, 2025, 02:55 PM UTC

   ChargeOver is accessible again. We are investigating root cause and investigating the outage.

3. resolved Oct 28, 2025, 03:04 PM UTC

   ChargeOver was inaccessible for most users from approximately 9:44am CT to 9:58am CT, due to a database connection issue. No data loss occurred. Scheduled subscription invoice creation and payment processing were not affected - all scheduled payments processed normally. We are still investigating root cause. A postmortem will follow.

Read the full incident report →

Started Jul 18, 2025, 07:11 PM UTC· resolved Jul 18, 2025, 08:14 PM UTC

1. investigating Jul 18, 2025, 07:11 PM UTC

   We are currently investigating this issue.

2. identified Jul 18, 2025, 07:44 PM UTC

   We believe we have identified an issue with third party analytics service causing the login process to take longer than expected to give users access to their instance.

3. monitoring Jul 18, 2025, 08:07 PM UTC

   Our third party analytics service was not being responsive and we've implemented a fix to bypass this issue. Logins should resume as expected. We're monitoring and will update with information as it becomes available.

4. resolved Jul 18, 2025, 08:14 PM UTC

   ChargeOver had longer than expected wait times from 14:11 CDT to 15:07 CDT. We're monitoring the solution to the root cause. A postmortem will follow.

5. postmortem Jul 23, 2025, 07:02 PM UTC

   # Incident details We received messages from internal & external users that they were not able to log into their instances. After investigation, we confirmed that the login sequence was taking an abnormal amount of time. This behavior was present on July 18th from `14:00 CST` to `15:14 CST`. The impact of this incident was limited to only the login process for ChargeOver. This did not affect payment processing, hosted pages, or other automated processes. # Root cause ChargeOver uses a third party metrics service, PostHog, to track user input to help improve the platform. Requests to PostHog were determined to be the cause of the slow login sequence. We found a URL endpoint was no longer being serviced, updated the pointing of our load balancer, and rebooted any systems in order for the change to take affect. # Incident timeline * 14:00 CDT - Received notice of logins not working. * 14:11 CDT - Assembled a team to start investigating root causes and update our status page. * 14:44 CDT - Identified the issue with the third party metrics service. Determined that logins were working, but they were taking significantly longer than expected. * 15:07 CDT - Implemented fix for third party metrics service and deployed to user instances. Began monitoring for any further issues. * 15:14 CDT - Verified that logins were working as expected and began drawing up plans for future remediation. # Remediation plan We understand that it is frustrating to lose access to your ChargeOver instance and we are very sorry that this has happened. In the future, we will handle these requests so that they do not get in the way of normal use by separating the logic independently of the rest of ChargeOver. We will also be implementing an SOP to make sure that any services that may cause disruptions won't affect the app in this way.

Read the full incident report →

Started Jul 05, 2025, 08:30 AM UTC· resolved Jul 05, 2025, 10:00 AM UTC

1. resolved Jul 08, 2025, 03:22 PM UTC

   ChargeOver was inaccessible from approx 3:27 CDT, to 4:57 CDT. This was a networking-system related outage. We are still investigating root cause. A postmortem will follow.

2. postmortem Jul 28, 2025, 03:04 PM UTC

   # Incident details On July 5th, a firewall-related issue caused ChargeOver to be inaccessible for approximately 90 minutes. Customers were unable to log in or access the ChargeOver application during this time frame. # Root cause At approximately 3:27pm CT, one of the high-availability firewalls experienced an error which caused it to stop passing traffic into/out-of ChargeOver’s internal network. Although the firewall was configured in a way which should trigger automatic fail-over \(we use industry standard Netgate firewalls, which use CARP to share IP and network status information and monitor for fail-over\) to a secondary firewall, the automatic fail-over did not occur. ChargeOver staff were immediately and automatically notified, and after troubleshooting were able to resolve the outage by power-cycling the affected firewall. # Incident timeline * 3:27pm CT - Firewall experiences an error, which stops some inbound/outbound traffic. ChargeOver staff are immediately alerted. * 3:28pm CT - ChargeOver staff respond and begin troubleshooting. * 4:57pm CT - Problem resolved after power-cycling the affected firewall. # Remediation plan We are still investigating what caused the error which took the firewall offline, as well as why the firewall did not fail over correctly to a secondary firewall when the error occurred. As we investigate further, we’ll have a better idea of whether this requires replacement or reconfiguration of the firewall. We are improving documentation, to enable our engineering team to troubleshoot quicker/isolate root cause quicker for future incidents. We are also working with data center staff to establish some better monitoring tools to help us troubleshoot quicker/isolate root cause quicker.

Read the full incident report →

Started Jun 08, 2025, 06:54 PM UTC· resolved Jun 08, 2025, 11:23 PM UTC

1. identified Jun 08, 2025, 06:54 PM UTC

   We are working with our primary data center to resolve the issue. At this time, we believe this to be a carrier networking issue at the data center itself, outside of ChargeOver's infrastructure.

2. resolved Jun 08, 2025, 11:23 PM UTC

   This incident has been resolved. A postmortem will follow.

3. postmortem Jun 27, 2025, 09:17 PM UTC

   We have posted a postmortem for this incident here: * [https://status.chargeover.com/incidents/3zfsdz4msf3s](https://status.chargeover.com/incidents/3zfsdz4msf3s)

Read the full incident report →

Started Jun 07, 2025, 09:00 PM UTC· resolved Jun 07, 2025, 10:21 PM UTC

1. investigating Jun 07, 2025, 09:00 PM UTC

   We are currently investigating this issue.

2. identified Jun 07, 2025, 09:42 PM UTC

   We have identified a networking issue, and are working on a resolution.

3. monitoring Jun 07, 2025, 10:11 PM UTC

   A networking fix has been applied, and services are coming back up. We are monitoring to ensure everything is accessible.

4. monitoring Jun 07, 2025, 10:11 PM UTC

   We are continuing to monitor for any further issues.

5. resolved Jun 07, 2025, 10:21 PM UTC

   This incident has been resolved. A postmortem will follow.

6. postmortem Jun 27, 2025, 04:33 PM UTC

   ## Incident details ChargeOver experienced an outage on June 7th, and an outage again on June 8th, as a result of a planned data center power outage, and an unplanned networking stack -related failure. On Saturday, June 7th, ChargeOver was inaccessible from approximately 13:12 CT to 16:53 CT. On Sunday, June 8th, ChargeOver was inaccessible from approximately 13:32 CT to 17:05 CT. ## Root cause ChargeOver’s primary data center \(Flexential in Chaska, MN\) performed a planned maintenance task which de-energized the four uninterruptible power supply \(UPS\) systems serving entire data center, one UPS system at a time. ChargeOver’s network infrastructure is designed to be redundant, and so ChargeOver has two separate power feeds coming from the four data center UPS systems. ChargeOver’s stacked network switches are plugged into either the first power feed, or the second power feed, to provide redundancy. When one of ChargeOver’s redundant network switches lost power due to the data center UPS maintenance, the expectation was that the switch would automatically fail over to the second redundant switch. Either the switches did not fail over correctly, or the switch lost it’s configuration on fail-over, which resulted in ChargeOver’s systems becoming unavailable to the outside world. ## Incident timeline * May 29 - Flexential informed ChargeOver of anticipated maintenance. Due to a miscommunication, it was unclear to ChargeOver staff that the maintenance would impact our environment. ‌ * June 7 - 13:12 CT - Flexential de-energizes and then re-energizes the first power feed, causing a network switch to go offline. The network switch either fails to fail-over correctly, or loses it’s configuration as the power feed comes back on. ChargeOver staff are immediately notified. * June 7 - 13:19 CT - Attempts to reset the network switch fail to restore service. * June 7 - 16:51 CT - One network switch is removed, and the configuration on the second switch is re-loaded. * June 7 - 16:51 CT - Network availability is restored. ‌ * June 7 - 13:32 CT - Flexential de-energizes and then re-energizes the second power feed, causing a network switch to go offline. The network switch either fails to properly boot, or re-loses it’s configuration as the power feed comes back on. ChargeOver staff are immediately notified. * June 7 - 14:41 CT - Attempts to reset the network switch fail to restore service. * June 7 - 17:03 CT - The configuration on the second switch is re-loaded. * June 7 - 17:05 CT - Network availability is restored. ## Remediation plan We deeply apologize for the downtime, and are already working towards many improvements towards our infrastructure. * We have replaced a suspected-faulty network switch. * We are working internally to establish some better procedures for coordinating planned maintenance intervals in the future. * We are investigating network switch options and fail-over configuration, to identify possible improvements we may be able to make to our network stack to avoid future service interruptions of this type. * We are investigating possible UPS upgrades or replacements we may be able to make to provide extra power redundancy beyond what is already provided by the Flexential data center.

Read the full incident report →

Started Mar 11, 2025, 12:00 AM UTC· resolved Mar 11, 2025, 12:00 AM UTC

1. resolved Mar 27, 2025, 12:30 PM UTC

   We have identified an issue where some emails sent the evening of March 10 / the morning of March 11 appear to be stuck in a SENDING state, instead of being delivered. We have identified and resolved an issue where an internal network attached storage device became disconnected, causing some emails to get stuck in a SENDING... state, instead of actually being delivered. We are still investigating root cause further.

Read the full incident report →

Started Jan 08, 2025, 12:52 PM UTC· resolved Jan 09, 2025, 12:27 AM UTC

1. identified Jan 08, 2025, 12:52 PM UTC

   We have identified an issue causing delayed syncs of data to QuickBooks Online, Xero, and Salesforce for a small subset of accounts. Data will still be synced to QuickBooks Online, Xero, and Salesforce automatically, but the sync to those systems may be delayed by several hours. Manual syncing of data will not be required. We are working on a resolution.

2. monitoring Jan 08, 2025, 03:24 PM UTC

   Data syncs to QuickBooks Online, Xero, and Salesforce are catching up quickly, but there is a significant number of items to sync before everything has fully caught up. Data will still be synced to QuickBooks Online, Xero, and Salesforce automatically, but the sync to those systems may be delayed by several hours. Manual syncing of data will not be required. We are continuing to monitor the situation.

3. monitoring Jan 08, 2025, 08:24 PM UTC

   Data syncs to QuickBooks Online, Xero, and Salesforce are catching up quickly, and are almost fully caught up. Data will still be synced to QuickBooks Online, Xero, and Salesforce automatically, but the sync to those systems may be delayed by a few more hours. Manual syncing of data will not be required. We anticipate syncing being fully caught up within the next ~8 hours.

4. resolved Jan 09, 2025, 12:27 AM UTC

   This issue has been resolved. All data syncs to Xero, QuickBooks Online, and Salesforce have caught up and fully synced.

Read the full incident report →

Started Nov 18, 2024, 09:44 PM UTC· resolved Nov 18, 2024, 10:07 PM UTC

1. investigating Nov 18, 2024, 09:44 PM UTC

   We are aware of ongoing issues with access to our platform. We are currently investigating and will release details here as they become available.

2. identified Nov 18, 2024, 09:58 PM UTC

   We've identified the problem and are implementing a fix.

3. resolved Nov 18, 2024, 10:07 PM UTC

   This incident has been resolved. A post-mortem containing further details to come.

4. postmortem Nov 21, 2024, 05:57 PM UTC

   ## Incident details On November 18th, ChargeOver suffered a partial service outage. Many customers were unable to access most parts of the ChargeOver application. ## Root cause ChargeOver has a cluster of redundant ingress servers which accept all application traffic, and then route that traffic internally to different backend services. This cluster of ingress servers \(HAProxy servers\) is backed by a distributed network file store \(GlusterFS\), which stores data \(encrypted SSL/TLS certificates\) needed by HAProxy to serve secure connections for incoming HTTP requests. Sometime between November 7th and November 17th, the connection between two of our ingress load balancers and our distributed network file store was disconnected. We are still investigating the cause of the disconnection. On November 18th, we deployed a routine update to our ingress load balancers. The deployment failed on 2 of the 3 redundant ingress load balancers due to the lost connection to the distributed network file store. This caused approximately 2/3 of traffic to ChargeOver to be dropped. The third ingress load balancer stayed active and continued to serve traffic. Automatic DNS fail-over occurred, automatically removing the 2 affected ingress load balancers from serving traffic within 5 minutes of the outage. ChargeOver staff were notified immediately. We restarted the two affected ingress load balancers to re-establish the distributed network file store connection, and re-deployed the ingress load balancer update. This restored access to all services. ## Incident timeline * Sometime between November 7th and November 17th - connection between load balancers and distributed network file store is lost * November 18 - 3:29pm CT - Our team starts a routine deployment to our ingress load balancers * November 18 - 3:33pm CT - The deployment completes, and we are immediately notified of a problem with 2 of the 3 load balancers * November 18 - 3:38pm CT - Automatic DNS fail-over removes 2 of our 3 ingress load balancers from DNS, as expected * November 18 - 3:44pm CT - We post an initial update to [https://status.chargeover.com/](https://status.chargeover.com/) of the partial outage * November 18 - 3:55pm CT - After assessing the situation, we reboot the two problematic load balancers * November 18 - 3:59pm CT - Re-deploy of the ingress update for load balancers succeeds across all 3 servers * November 18 - 4:02pm CT - Our team confirms everything looks good, and DNS fail-over automatically adds the 2 failed servers back to DNS * November 18 - 4:07pm CT - Update posted to [https://status.chargeover.com](https://status.chargeover.com)/ indicating the issue has been resolved ## Remediation plan We’ve identified a number of take-aways from this incident. * We are implementing additional monitoring to proactively monitor the connection between the ingress load balancers and the distributed network file store. * We are discussing possible solutions to reduce/remove the dependency on the distributed file store from the load balancers. * There were several internal DNS names which pointed at specific ingress load balancers, rather than using the round-robin, more fault-tolerant DNS which our public services use. This hampered our ability to recover from this situation more quickly, so we are moving those internal DNS names to use round-robin DNS.

Read the full incident report →

Started Nov 12, 2024, 05:05 PM UTC· resolved Nov 12, 2024, 06:10 PM UTC

1. investigating Nov 12, 2024, 05:05 PM UTC

   We are receiving reports that some customers are having trouble accessing the ChargeOver app. We are investigating further. All ChargeOver services appear to be operating normally, but it looks like some web traffic may be having problems accessing ChargeOver services.

2. investigating Nov 12, 2024, 05:35 PM UTC

   All ChargeOver services are operating normally. Some customers are having trouble accessing ChargeOver. At this time, we believe this is due to a carrier network routing issue outside of ChargeOver. We are still investigating and working with our data center providers to get more information.

3. monitoring Nov 12, 2024, 05:50 PM UTC

   All ChargeOver services are operating normally, and are accessible to everyone now. A networking or connectivity incident occurred with our data center provider (Flexential) which prevented some customers from accessing ChargeOver. We are still waiting for full details, and then will post an update. We continue to monitor connectivity. We believe any impact is now resolved, and everyone should be able to access ChargeOver at this time. An update will follow with more details.

4. resolved Nov 12, 2024, 06:10 PM UTC

   All connectivity issues are resolved now. Our primary data center (Flexential - Chaska) experienced a networking issue which impacted the ability to connect to ChargeOver services for some customers.

5. postmortem Dec 02, 2024, 05:29 PM UTC

   ## Incident details On November 12th, some customers had trouble accessing ChargeOver. This was a networking issue at the primary data center ChargeOver is hosted within. ## Root cause On 12 November at 10:26 CT, ChargeOver began receiving automated reports of connectivity issues. The issue was tracked down to a networking issue at the data center ChargeOver’s primary location is within \(Flexential in Chaska, MN\). The problem was immediately escalated to Flexential engineers who identified an internet circuit at Flexential’s Chicago POP as the source of the issue. Flexential opened a ticket with the circuit provider who confirmed there was an issue with packets over a certain size traversing the device due to an MTU misconfiguration. The circuit provider confirmed that they fixed the issue, however Flexential kept production traffic off the link while more investigation is performed. Total impact to service was around 41 minutes. ## Incident timeline * Nov 12 - 10:26am CT - ChargeOver’s automated uptime monitoring identifies and alerts our engineering team of an issue * Nov 12 - 10:53am CT - ChargeOver identifies the issue as a bandwidth/networking issue outside of the ChargeOver network, and escalates the issue to Flexential engineering * Nov 12 - 11:05am CT - Flexential resolves the issue ## Remediation plan ChargeOver is working with our data center provider Flexential to improve monitoring and connectivity.

Read the full incident report →