Magento and Adobe Commerce hosting generates a very particular kind of ticket queue. A slow category page, a stuck indexer, a cron job that stopped running, a Varnish purge that did not purge: each one needs someone who understands the stack, not just the server. This shared support team checklist for Magento hosting providers sets out what an outsourced team must be able to cover before you trust it with your customers' stores.
The checklist is written for hosting company owners and support managers who are weighing a shared support team for hosting companies against hiring more in-house engineers. Use it to test any provider, including us, and ask for an itemised quote against your own list.
Why Magento tickets are different from generic hosting tickets
A shared hosting ticket might be a mailbox or a DNS record. A Magento ticket usually touches several moving parts at once, and the merchant reporting it often has revenue on the line.
- Many layers: PHP-FPM, the web server, Varnish, Redis, the database, OpenSearch and message queues all affect one page load.
- Version coupling: each Magento release supports a specific range of PHP, database and OpenSearch versions, so one upgrade can force another.
- Background work: indexers and cron drive prices, stock, catalogue visibility and emails. When they stall, the store looks broken even though the server is healthy.
- Peak sensitivity: merchants run promotions, and checkout downtime during a sale is the ticket nobody forgives.
A shared team that only handles generic Linux issues will escalate most of these back to you. The checklist below shows what real coverage looks like.
Checklist part one: performance and caching
Performance complaints are the most common Magento ticket. The team should be able to work through them in a repeatable order instead of guessing.
- Full page cache triage: confirm whether pages are being served from Varnish or the built-in cache, check hit and miss behaviour and identify what is bypassing the cache, such as cookies or custom blocks.
- Varnish configuration: review the VCL generated by Magento, health probes, grace settings and how purges are sent when products or categories change.
- Redis sessions and cache: separate instances or databases for cache and sessions, sensible memory limits, eviction policy and monitoring for connection errors.
- PHP-FPM tuning: worker counts matched to memory, OPcache settings and slow log review.
- Database load: slow query review, lock waits and checks for oversized log tables left behind by extensions.
- Deploy mode and static content: production mode, compiled code and static assets deployed correctly after every release.
Checklist part two: indexers, cron and queues
These are the quiet failures. Nothing alarms, yet orders, stock and prices drift out of date.
- Indexer status: spot indexers stuck in "processing" or marked invalid, and know when to reset them safely and when to investigate a lock first.
- Update on save versus schedule: understand the trade-off and advise the merchant, especially for large catalogues.
- Cron health: confirm the Magento cron group is running as the right user, jobs are not overlapping and the cron schedule table is not bloated.
- Message queue consumers: make sure consumers are running under a supervisor and restart cleanly after deploys.
- Reindex after bulk imports: plan reindexing around trading hours, not in the middle of them.
Checklist part three: versions, search and security patches
Version management is where hosts either build a reputation or lose one. The team must treat it as a calendar item, not an emergency.
- PHP version compatibility: check each store's Magento version against supported PHP versions before changing anything, and warn merchants when their version is approaching end of support.
- OpenSearch or Elasticsearch: confirm the engine version matches the Magento release, watch cluster health and handle reindexing after search upgrades.
- Security patches: track Adobe's published patches and isolated fixes, test them on staging and apply them promptly, with a record of what was applied and when.
- Extension risk: flag outdated third-party modules that block upgrades, and report them to the merchant instead of silently working around them.
- Hardening basics: admin URL protection, two-factor authentication for the admin, file permission review and malware scanning on a schedule.
Checklist part four: sales events and checkout downtime
Merchants will judge your hosting by how it behaves on their busiest day. A shared team should have a written playbook for it.
- Pre-sale readiness review: a short review a few days before a known promotion covering caching, queue depth, database headroom and recent deploys.
- Load expectations: a conversation with the merchant about expected traffic, so capacity decisions are not made during the event.
- Change freeze: agreed windows when no deploys, reindexes or upgrades happen.
- Checkout monitoring: synthetic checks that test the cart and checkout path, not just the home page.
- Live-event escalation: a named contact path, fast acknowledgement and clear status updates while an incident is in progress.
- Post-incident write-up: a plain account of cause, fix and prevention that you can pass to the merchant.
Checklist part five: how the team works with your business
Technical skill is only half of it. A shared team becomes your brand in front of customers, so the working arrangement matters.
- White-label communication: replies sent under your name and tone, inside your helpdesk, not a separate vendor portal your customers see.
- Clear tiering: what the shared team resolves alone, what it escalates to you and what it escalates to the merchant's developer.
- Documented runbooks: written procedures for recurring Magento issues, kept current and shared with you.
- Access discipline: least-privilege access, individual logins, and a record of who touched which server.
- Coverage hours: written response expectations for the hours you promise your own customers.
- Reporting: regular summaries of ticket themes so you can spot stores that need an upgrade or a plan change.
Magento support coverage table
Use the table below as a scoring sheet when you interview providers. Mark each row as covered, partly covered or not covered.
| Area | Typical ticket | What the team should do | Evidence to ask for |
|---|---|---|---|
| Page speed | Slow category or product pages | Trace cache misses, review Varnish and PHP-FPM, check slow queries | Sample triage notes with sensitive details removed |
| Cache layers | Changes not appearing, purge failures | Verify Varnish purge path, Redis health and configuration cache state | Written cache troubleshooting runbook |
| Indexers | Stale prices or stock, invalid indexers | Inspect status, clear locks safely, reindex outside trading hours | Documented reindex procedure |
| Cron | Emails, imports or schedules not running | Check cron user, overlaps and schedule table, restart cleanly | Cron health check list |
| Versions | Upgrade requests, end-of-support warnings | Match PHP, database and OpenSearch to the Magento release, test on staging | Compatibility checklist and upgrade plan template |
| Security | Patch requests, suspicious files | Apply published patches, scan, harden admin access | Patch log format and scanning schedule |
| Sale events | Checkout slowdown or outage | Run pre-sale review, monitor checkout path, escalate fast | Event playbook and incident write-up sample |
| Communication | Customer updates during incidents | Reply white-label inside your helpdesk with clear status updates | Reply templates and escalation matrix |
Any row marked "not covered" is a ticket category that will return to your own engineers, so weigh those gaps against what you are actually paying for.
What affects the price of a shared Magento support arrangement
We do not publish figures in an article, because the right number depends on your scope. These are the factors that move the price, so you can compare quotes fairly.
- The number of Magento stores and the size of their catalogues.
- Coverage hours, including nights, weekends and public holidays.
- Response time commitments for urgent tickets.
- Whether sale-event standby and pre-sale reviews are included or charged separately.
- Whether patching and version upgrades are included or billed as projects.
- The mix of hosting environments, such as dedicated servers, cloud instances or managed platforms.
Ask every provider for an itemised quote that separates routine ticket handling, patching, event cover and project work. A single blended number hides what you are actually buying.
Questions to ask before you sign
- Who on your team has handled Magento 2 or Adobe Commerce stores in production?
- How do you decide when to reset an indexer and when to investigate first?
- What is your process when a merchant's extension blocks a security patch?
- Can we see an example runbook and an example incident write-up?
- What happens to our documentation and access records if we end the arrangement?
A confident team answers these with specifics. A vague answer to the indexer or patch question is a useful warning. You can also read how we structure these arrangements on our shared support plans for web hosts page.
Why Companies Choose CloudHouse for Shared Team Support
Hosting companies work with CloudHouse because we plan the onboarding in stages, stay available for support after the arrangement goes live and give transparent, itemised quotes so you can see what each part of the coverage costs. We document the runbooks we use, so your own staff can follow them too.
Conclusion
A good shared team for Magento hosting is measured by how it handles caching, indexers, cron, version compatibility, security patches and sale-day checkout, and by how well it represents your brand while doing so. Use the checklist and table above to test any provider, and insist on written evidence for each row. To discuss your own Magento ticket mix and receive an itemised proposal, visit our shared team support for hosting companies page and request a quote.
