Maropost outage history

We have identified intermittent spikes causing some merchants to receive a “We’ll be back shortly” error when navigating the Control Panel. We are continuing to investigate and make improvements to prevent these errors from occurring.

We are currently seeing increased bot traffic that is bypassing some of our existing safeguards. We have added further protections, which are helping reduce the impact. However, the traffic patterns continue to change, so we are making ongoing adjustments to our mitigations. We are currently using a more aggressive approach and closely monitoring the situation. We will provide further updates as the situation progresses.

On Aug 4, 2026 through Aug 6, 2026, some customers experienced intermittent slowness and errors across parts of the system during several short periods. Our team identified elevated traffic and processing load as the cause, reduced the load, and restored stable performance. The incidents were caused by a large increase of sophisticated bots that Cloudflare miscategorized and treated as human traffic. The issue is resolved and we continue to monitor the system. We are collaborating with Cloudflare to improve detection of these requests and reduce their impact going forward.

We are receiving reports of control panels receiving "We will be back online shortly". Our Development Team are investigating now.

We have identified the issue and our Development Team is working to resolve it as soon as possible.

Our team has deployed a fix and is closely monitoring the situation to ensure services return to normal.

The issue has been resolved and services are operating as normal.

On 27 July 2026, a subset of merchants experienced an issue accessing their control panels. Affected users were shown a “We will be back online shortly” message after attempting to log in. The incident began at **11:48 AM AEST** and was resolved at **1:17 PM AEST**, for a total duration of **1 hour and 29 minutes**. ## What happened During a production software release, a change affecting a security-related control panel configuration caused authenticated requests to fail for a subset of control panels. The issue only affected control panels where the relevant security feature was enabled. Users could reach the login page, but after authentication they were unable to access the control panel. ## Impact Some merchants were temporarily unable to access their control panels and complete administrative tasks. The disruption was limited to a subset of control panels. Services returned to normal once the affected configuration was disabled. ## Timeline * **11:48 AM AEST** – Reports were received of control panels displaying “We will be back online shortly,” and the Development Team began investigating. * **12:35 PM AEST** – The cause of the issue was identified and remediation work began. * **12:55 PM AEST** – A fix was deployed and the service was placed under monitoring. * **1:17 PM AEST** – The issue was confirmed as resolved and services were operating normally. ## Root cause A change included in the production release caused an incorrect security reporting configuration to be generated for affected control panels. This produced a response header that exceeded the supported size limit, causing authenticated control panel requests to fail. ## Resolution The affected security feature was disabled, immediately restoring access to impacted control panels. A permanent code correction is also being implemented so the feature can operate without generating the invalid configuration. ## Preventive actions To reduce the likelihood of a similar incident, we are: * Adding regression coverage for authenticated control panel access when security-reporting features are enabled. * Expanding staging validation for response-header size and security configuration changes. * Improving release checks for feature-toggle combinations before production deployment. * Implementing the permanent code correction and validating it before re-enabling the affected feature. We apologise for the disruption and appreciate the patience of affected merchants while our teams worked to restore access.

We are currently investigating reports of intermittent slowness affecting the Neto Control Panel.

Our team has deployed a fix and is closely monitoring the situation to ensure services return to normal.

This incident has been resolved.

On Jul 24, 2026, some customers experienced intermittent slowness across parts of the service during two short periods. Our team identified elevated traffic and processing load as the cause, took action to reduce the load, and restored stable performance. The issue is now resolved and we are continuing to monitor closely. We are taking steps to improve resilience and help prevent similar issues from recurring.

We are currently investigating reports of intermittent slowness affecting the Neto Control Panel. Users may experience delays while accessing or navigating the Control Panel. Our Engineering teams are actively investigating the issue to identify the root cause and restore normal performance as quickly as possible.

The issue has been identified and a fix is being implemented.

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

This incident has been resolved.

On **July 23, 2026**, customers experienced intermittent slowness while accessing the **Neto Control Panel**, impacting approximately **20% of requests**. The issue was caused by an infrastructure configuration change that introduced a mix of instance types with different performance characteristics, resulting in some instances becoming overloaded under production traffic. Our engineering team resolved the issue by removing the affected instance type, replacing the impacted instances with compute-optimized instances, and updating the infrastructure configuration to prevent recurrence. We are also implementing additional improvements to our load-balancing configuration and infrastructure validation processes to further enhance platform reliability.

Australia Post has reported an API degradation impacting the performance of Label Printing APIs. For the latest updates, please refer to the Australia Post developer status page: https://status.developers.auspost.com.au/incidents/l1qmd679b34p Please note that we are currently experiencing degraded performance on Label Printing APIs Our teams are currently investigating and we will keep you informed as we work to resolve the issue. Australia Post apologise for any inconvenience caused.

UPDATE from Australia Post Incident status: Monitoring A fix has been implemented and we are monitoring the results. https://status.developers.auspost.com.au/incidents/l1qmd679b34p

Incident resolved This incident has been resolved.

We are currently aware of an issue affecting eBay integration, with an error message appearing stating: "Listing Duration is required. Record Skipped.". Our Development Team is actively investigating the issue.

We are continuing to investigate this issue.

The issue has been identified and a fix is being implemented.

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

This incident has been resolved.

### Summary On 22 July 2026, merchants using the eBay integration experienced listing updates being skipped with the following error: > “Listing Duration is required. Record Skipped.” The incident was reported at 9:42 AM AEST and resolved at 4:40 PM AEST, with a total duration of approximately 6 hours and 58 minutes. We apologise for the disruption caused to merchants using the eBay integration. ### Impact During the incident, affected eBay listing records could not be processed successfully. This may have prevented merchants from creating or updating listings through the integration. Merchants who saved an eBay listing rule template while the issue was present may also have had some template fields saved without their expected values, despite the correct value continuing to appear in the interface. Other platform services were not affected. ### Root cause An internal data import process used to update shared eBay information was cancelled before it had completed. Because the process had already updated part of the dataset, its cancellation left required eBay information incomplete. This caused subsequent listing updates to fail validation and be skipped. A direct backup and restoration process for the affected shared database was not available. Our Development Team therefore used a point-in-time database recovery process to retrieve and restore the affected information. ### Resolution Our Development Team restored a production database to a separate recovery environment and extracted the affected tables. The recovered information was then restored across each of the relevant production database clusters. The first restoration was validated by Development and Support before the remaining clusters were updated. After the restoration was completed, we monitored the integration to confirm that eBay listing records were processing successfully before marking the incident as resolved. ### Merchant follow-up Merchants who saved an eBay listing rule template while the incident was occurring should re-save the affected template. To identify whether a template was changed during the incident: 1. Log in to your control panel. 2. Open **Reports**. 3. Select the **Staff User Log** report. 4. Enter `ebaytmpl` in the **Page Type** field. 5. Enter `edit` in the **Process** field. 6. Review edits made during the incident window. 7. Note the affected template IDs shown in the **Notes** column. 8. Open and re-save each affected eBay template. The **Listing Duration** field may have been saved as blank even though the interface continued to display “GTC.” Merchants who do not use eBay Business Policies should also review the fields under the template’s **Returns** section, as these fields may need to be re-entered before the template is saved. ### Timeline All times are in AEST on 22 July 2026. * **9:42 AM** – Investigation commenced after reports of eBay listing records being skipped. * **11:24 AM** – Point-in-time database restoration commenced. * **11:37 AM** – The recovery database was successfully restored. * **11:50 AM** – The affected information was extracted and prepared for restoration. * **12:05 PM** – Restoration of the first production database cluster was completed. * **12:11 PM** – Development and Support confirmed that the first restoration was successful. * **12:17 PM** – Restoration commenced across the remaining database clusters. * **12:43 PM** – Restoration was completed across all remaining clusters. * **2:33 PM** – The fix was confirmed as implemented and monitoring commenced. * **4:40 PM** – Monitoring confirmed that the integration was operating successfully and the incident was resolved. ### Follow-up actions We are reviewing the following improvements: * Adding safeguards around the cancellation of data import processes so that partially completed updates cannot leave shared information in an incomplete state. * Improving validation and recovery procedures for shared eBay integration information. * Restoring a working shared-database backup process to provide a faster and more targeted recovery option. * Reviewing whether additional validation can prevent templates from being saved when required underlying values are missing.

We are investigating an issue where some Neto stores are receiving 503 errors on API requests.

Our team has deployed a fix and is closely monitoring the situation.

The issue has been resolved. Our team will continue to closely monitor the situation.

We are experiencing a service disruption for the Neto Control Panel and Storefronts. We are investigating the solution and will post an update as soon as possible.

We have identified the issue and have traced to a corruption in the Network File System. We have made the appropriate corrections and the system has begun recovering.

The fix to the Network File System is resolved and service is restored. We are continuing to monitor the platform to ensure its availability and stability.

On 8 July 2026, we experienced an infrastructure issue that affected all Neto merchant webstores and cPanels for approximately 1 hour and 30 minutes. The incident was caused by a failure within our shared file system infrastructure, which prevented critical services from accessing the files required to serve websites and cPanels. As a result, the platform automatically blocked new requests to protect data consistency, leading to service disruption across all Neto stacks. Our engineering team responded immediately by restoring the affected file system services, failing over to a healthy infrastructure instance, and replacing impacted virtual machines. Once these recovery actions were completed, all webstores and cPanels were restored to normal operation. We are continuing our investigation to determine the underlying reason for the file system process failure. Based on our findings, we will implement additional monitoring and alerting, along with any necessary infrastructure improvements, to help detect and prevent similar incidents in the future.

We are currently investigating an issue related to the error message “Something Went Wrong” affecting users configuring Unified Login.

We are continuing to investigate this issue. We will provide further updates as more information becomes available.

Our team has identified and resolved the issue. If you created a Unified Login account and encountered the “Something went wrong” error, your account was still successfully created. Please use the credentials you set to log in as normal via app.maropost.com If you continue to experience any issues, please contact our support team for assistance.

We are currently investigating a potential service interruption affecting SFTP connections for some Neto stores. During this time, some users may experience difficulty connecting via SFTP.

We have identified an issue affecting DNS resolution for a service domain used by Neto's SFTP infrastructure. Our team is actively working with the relevant service providers to restore normal operation as quickly as possible.

The issue affecting SFTP connectivity has now been resolved, and SFTP services are operating normally.

The issue affecting SFTP connectivity has been resolved and services are operating normally. We apologize for the disruption and appreciate your patience while we worked to resolve the issue.

The Neto Core Checkout page is currently unavailable for some merchants and is returning a 504 Gateway Timeout error. We have identified the issue and are actively investigating it on top priority.

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

This incident has been resolved.

We are currently investigating this issue.

The “Sorry, you have been blocked” error in cPanel has been identified as false positives triggered by Cloudflare. We are actively working with Cloudflare, who are investigating the issue and helping implement a fix. We will provide further updates as they become available. Thank you for your patience.

This incident has been resolved.

We are currently investigating this issue.

The issue has been identified and a fix is being implemented.

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

This incident has been resolved.

We are receiving reports of sites receiving "We will be back online shortly". Our Development Team are investigating now.

We are receiving reports that services are returning to normal. We are continuing to monitor the situation.

Some sites may still show "We will be back online shortly" intermittently. Our Development Team is working to resolve the issue as soon as possible.

This incident has been resolved.

### Summary On 4 May 2026, some merchants experienced intermittent access issues with their webstores and Control Panel. During this time, some sites may have displayed a “We will be back online shortly” message. ### Impact The issue caused intermittent availability issues for some merchant webstores and Control Panel access. The impact was not consistent across all sites, and some requests may have succeeded while others failed. ### Root Cause The issue was caused by a sudden spike in automated crawler traffic, which created increased load on the caching layer. This prevented some new connections from being established and resulted in intermittent availability issues. ### Resolution The traffic pattern was identified, and mitigation was applied to reduce the impact of the abnormal traffic while maintaining access for legitimate crawler activity. ### Preventative Actions We have strengthened traffic protection rules to better manage sudden high-volume crawler activity. We are also continuing to monitor traffic patterns and refine platform protections to reduce the risk of similar disruptions.

We are receiving reports of sites receiving "We will be back online shortly". Our Development Team are investigating now.

We are receiving reports that services are returning to normal. We are continuing to monitor the situation.

The issue has been resolved and services are operating as normal.

### Summary On 30 April 2026, some merchants experienced intermittent disruption when accessing storefronts and the Control Panel. During the incident, some storefront pages may have intermittently displayed a “We’ll be back online shortly” message, while some Control Panel access may also have been affected. The incident was caused by a significant spike in automated traffic directed at the platform, which placed abnormal load on the caching and application layers. This resulted in intermittent availability and degraded performance for affected services. ### Root Cause The disruption was caused by a large volume of automated traffic targeting the platform. This traffic created abnormal load on the caching layer, which is used to support efficient delivery of storefront and Control Panel content. As traffic volumes increased, the caching and application layers became degraded, resulting in intermittent access issues for some merchants. ### Resolution Our teams identified the unusual traffic pattern and implemented targeted mitigation rules to reduce the impact of the automated traffic. Once the mitigation was applied, the caching and application layers stabilised, and services returned to normal. We continued monitoring after service recovery to ensure the platform remained stable. ### Preventative Actions To reduce the likelihood and impact of similar events in future, we have taken the following actions: * Strengthened traffic filtering and mitigation rules for abnormal request patterns. * Improved monitoring for sudden traffic spikes and automated traffic fingerprints. * Reviewed the traffic behaviour with our traffic protection provider to better identify similar patterns in future. * Continued tuning of platform protection rules to reduce the impact of high-volume automated traffic.

We are currently aware of an issue affecting eBay integration. eBay has confirmed a DNS resolution issue impacting their APIs, which may result in errors (including “error 0”) and failed or delayed syncs. You can view eBay’s official update here: https://developer.ebay.com/support/api-status/production/dns-resolution-failure-for-api-ebay-com

eBay has identified a DNS resolution issue affecting their APIs: https://developer.ebay.com/support/api-status/production/dns-resolution-failure-for-api-ebay-com While there is no official confirmation of full resolution yet, we are seeing partial recovery, with processes starting to work for some merchants.

eBay has provided an update on their status page: https://www.ebay.com.au/sts?msockid=37d317c345a462fa0d8002bf446263f5 We're aware that some customers have been experiencing intermittent technical issues since Sunday on parts of the eBay platform. We appreciate your patience as we work to resolve this. eBay will protect your seller performance, including removal of: - Negative or Neutral Feedback related to the intermittent technical issues - Defects resulting from impacted orders (cancellations and claims closed without seller resolution) We will also protect your valid tracking upload rate metrics and on time shipping metrics from any impact. If you had an auction end after April 26, 12:01 pm PT, which you feel was impacted, you have the option to cancel the order and we will protect your seller performance and refund associated selling and ad fees. We know how important a reliable marketplace is and we appreciate your patience as we address this. Future updates from us will continue to be posted here.

The issue impacting eBay integration appears to be resolved for affected merchants. This was related to a broader incident on eBay’s side. We recommend continuing to monitor the eBay API status page: https://developer.ebay.com/support/api-status/production/dns-resolution-failure-for-api-ebay-com and eBay system status page: https://www.ebay.com.au/sts?msockid=37d317c345a462fa0d8002bf446263f5 for any further updates. If you are still experiencing issues, please reach out to Neto support so we can investigate further.

We are receiving reports of some cPanel pages showing "Software Error". Our Development Team are investigating now

Services are returning to normal. We are continuing to monitor the situation.

All services are now running normally.

### Summary On 27 April 2026, some merchants experienced intermittent issues accessing cPanel, with some pages returning a “Software Error” message or taking longer than expected to load. The issue was short-lived and services stabilised shortly after the initial disruption. We continued monitoring the platform before marking the incident as fully resolved. ### Customer Impact During the incident window, some merchants may have experienced temporary delays or errors when accessing cPanel. The issue did not impact all merchants. ### Root Cause The disruption was caused by a brief spike in database load, which temporarily affected the platform’s ability to serve some cPanel requests normally. ### Resolution Our monitoring detected the elevated load, and the platform’s automated scaling processes responded by provisioning additional capacity. Once the load reduced and scaling completed, cPanel access returned to normal. No manual intervention was required, and services stabilised within minutes. ### Preventive Actions The platform’s existing monitoring and auto-scaling processes operated as expected and allowed the system to recover automatically. We will continue to monitor platform performance and capacity to help maintain service stability during future load spikes.

We are currently investigating an issue causing degraded performance on some Neto stores. We are actively working to identify the root cause and restore normal performance as quickly as possible.

The issue has been identified and a fix is being implemented.

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

This incident has been resolved.

We are currently investigating an issue affecting some stores using the Australia Post Public API for shipping rate calculations. Affected merchants may experience no shipping options displaying at checkout, which can prevent customers from completing orders. We are working actively with Australia Post to resolve it as a priority. Workarounds While we continue working towards a resolution, merchants can use the following temporary options to restore checkout functionality: If you are using eParcel: Switch your shipping rate calculator from the Australia Post Public API to the eParcel rate calculator. If you are not using eParcel: Set up a backup flat rate in your Australia Post shipping table and configure it as a fallback. This allows customers to continue checking out if live rates are unavailable. If you need assistance applying these workarounds, please contact our support team and we’ll be happy to guide you through the setup. We will continue to provide updates as more information becomes available

We have identified a likely cause of the issue affecting Australia Post shipping rates for some stores. Our team is currently working on a hotfix to update the integration to Australia Post’s updated API service. This is expected to restore functionality for affected stores.

The issue affecting Australia Post freight calculations has now been resolved. We appreciate your patience while we worked to restore normal service.