#FE: Premium Hosting Care screens (from backend Phase 14)
Frontend spec for backend Phase 14 — Premium Hosting Care add-on — requirements complete 2026-10-07, not built, same flow as V7. V8 requirement A managed support pack: a private Slack support channel and proactive uptime monitoring of the user's apps.
Add-ons page — buy for 1, 6 or 12 months
from credit (discounted) or straight through a gateway
Slack — the user gives an email; the support team invites them by hand
App Settings tab — monitoring on / off per app; the switch and results live in Central, not OSS
Alerts — up / down changes only, through the notifications phase
i18n namespaces: addons.premiumCare.*, premiumCare.slack.*, premiumCare.monitoring.*.
#A. Buying and keeping it
| # | Feature | Screen / control | Rules from the backend doc | Frontend notes |
|---|---|---|---|---|
| 14.1 | Buy | Add-ons card → Buy CONFIRM | Per account, bought separately — never part of a plan (7.26). Cycles 1, 6 or 12 months. Two ways to pay (clarified 2026-10-07): from the credit balance, or buy directly with card / PayPal / a gateway in one step (Phase 6) — that payment adds the credit and the pack is bought automatically when the user comes back. Tax added, charge saved, purchase email and activity-log entry (as V7) | The two routes do not cost the same, because the discount only applies to the credit route (14.2) — so this is not a styling choice between two buttons. The confirm is a small checkout: cycle, price, tax, total and the balance left. From credit: if the balance is short, give the exact shortfall and offer Add credit — never a bare "insufficient funds". Direct: the user leaves for the gateway and comes back to a pack already bought, so the return screen must confirm both things happened, in that order, and must not look like a top-up that did nothing. The three cycles are a radio choice, not a dropdown, because the discount makes the longer ones materially different |
| 14.2 | Prices & discounts | Same confirm | Admin-managed in V8 — price per cycle, renew price and the discount rules (V7 hardcoded them). Clarified 2026-10-07: the discount applies only when the pack is paid from the credit balance (as V7) | This is the sharpest thing on the page: the same pack costs more if you pay by card. So the confirm has to show both prices side by side — the credit price with its discount, and the direct price without — and let the user choose knowingly. Hiding it would be the kind of surprise people notice on the receipt. Read every number from the API; the V7 percentages are deliberately not written here, because the admin owns them now — the same rule this spec follows for plans. Also the renew price can differ from the buy price, so the card shows what was paid and what the next renewal will cost |
| 14.3 | Renew | Automatic, with the card showing the date | The pack has its own expiry date. "Expires soon" emails; on the expiry date it auto-renews from credit at the renew price (charge plus a "renewed" email); not enough credit → it expires with an "expired" email. The same engine as plans | "Same engine as plans" is the useful part: the expiry, renew and reminder behaviour already specced for plans (7.10, 7.11) can be reused rather than designed again. The card shows next renewal date and price, and warns when the balance will not cover it — this is the one case the user can prevent, so the warning must appear before the date, not after |
| 14.4 | Cancel | Cancel CONFIRM | Stops auto-renew. The pack keeps working until its expiry date (cancel email), as V7 | So Cancel is not "turn off now", and the confirm must say the real date it stops. After cancelling, the card reads active until <date> with a Resume path that simply turns auto-renew back on — the same shape as a cancelled plan (7.9) |
| 14.8 | When it ends | Automatic | Proactive monitoring stops for all apps. Support-channel access is handled by the support team | Two different endings in one item. The monitoring half is ours: the per-app switches must become unavailable with the reason, and the app screens must not imply monitoring is still running. The Slack half is not ours — the screen should not promise the channel is closed or kept, because Central does not control it |
| 14.10 | Activity log | Existing activity log | Purchase, renew, cancel, expiry and per-app monitoring on / off are recorded | New event types for the existing log. Unlike Log Monitoring (13.9), these entries name an app as well as the account, because the per-app switch is real here |
#B. The Slack support channel
| # | Feature | Screen / control | Rules from the backend doc | Frontend notes |
|---|---|---|---|---|
| 14.5 | Slack support channel | Email field after buying, then a waiting state | The user enters their email; the support team invites them to a private Slack channel by hand (as V7) | The honest design here is a waiting state, not a success message. Nothing happens automatically, so after saving the email the screen says an invitation will arrive from the support team — with no progress bar and no estimate, because Central cannot see any of it. Let the user change the email afterwards, since a typo would otherwise be unfixable. This confirms what the frontend doc already carried from V7 — a Slack-invite step with an email — so nothing changes there |
#C. Proactive monitoring
| # | Feature | Screen / control | Rules from the backend doc | Frontend notes |
|---|---|---|---|---|
| 14.6 | Monitoring per app | The app's Settings tab — named by the backend on 2026-10-07 | Only with Premium Hosting Care, and a Central-only option: the switch lives in the App Settings tab in Central, and without the add-on it is hidden or locked. Central checks each enabled app's public URL from outside, every 7 minutes: status code, response time, status (up / down / SSL error). The switch and the check results are saved in Central — OSS is not involved. phpMyAdmin apps are skipped, and an app deleted in OSS is turned off | The backend has now placed it, which settles half of D-47: it is the app's Settings tab. The catch is that Settings is itself one of the app tabs with no slot in the fixed app menu (D-40), so this lands inside an unresolved question rather than outside one. "Hidden or locked" is a real choice and the backend allows either — this spec recommends locked with the add-on named, because unlike a plan feature the user can act on it immediately, which is exactly when an upsell is honest rather than annoying. And the backend has since settled the same question for WP Toolkit the same way: 16.13 (2026-10-08) says a user without that add-on sees its tab locked, with the price and a Buy button. Two add-ons should not differ here, so treat that as the precedent. And note what is different about this one: every other app screen reads through the server's OSS panel, but here Central calls the public address from outside and keeps the result itself — so it survives an unreachable panel and is the only place a user sees their site as the internet sees it. Say every 7 minutes plainly, so nobody expects a live reading; show that phpMyAdmin apps are skipped rather than omitting the switch; and treat "turned off because the app was deleted in OSS" as an explained state, not a silent flip |
| 14.7 | Uptime alerts | Nothing to build | Sent only when the status changes — up → down, down → up — with no repeats. An SSL error that still answers 200 is not alerted. They go through the notifications phase (Alerts group: email, in-app, channels) | The no-repeat rule matches Phase 11's own (11.14), so nothing new. The SSL exception is worth surfacing on the screen rather than only in an alert: an app can read SSL error in its status and the user will never be emailed about it, which looks like a broken alert unless the screen explains it. Showing status code and response time next to the status is what makes that make sense |
#What this phase answers
| Open item | Answer |
|---|---|
| Premium Care was "its own phase, later" on FE: Notifications & mail, FE: Plans & subscription and Product overview | It is now a written phase (14.1–14.10) V8 requirement — the fourth add-on to get one, after White label (12) and Log Monitoring (13) |
| Why is Premium Hosting Care "not assignable" to a plan? (7.26) | 14.1 confirms it: it is bought per account, on its own, with its own cycle and expiry. A plan can never include it, so the add-ons card never reads Included for this one |
| What happened to V7's "uptime monitor"? | It is 14.6 / 14.7 — per-app, every 7 minutes, from outside, alerting only on a change of status. The V7 notification map row that pointed at "the Premium Care phase" now has a home |
| V7's Premium Care emails (purchase, expires soon, expired, auto-renew, cancel) | All kept, driven by the same expiry engine as plans (14.3, 14.4) |
| V7's sales counter ("X of Y sold" on the offer) | Not in V8 — so no scarcity display, and no screen should imply a limited quantity |
| Where does the monitoring switch live? | Answered 2026-10-07: the app's Settings tab, as a Central-only option that is hidden or locked without the add-on. Half of D-47 — the status display still has no stated home, and Settings itself is one of D-40's unplaced tabs |
| Is Premium Hosting Care's monitoring an OSS feature? | No — answered 2026-10-07. The switch and the check results are saved in Central; OSS is not involved at all. That is why it keeps working when a panel is unreachable |
#Still open after this phase
| # | Question |
|---|---|
| D-47 | Half answered on 2026-10-07: the switch belongs in the app's Settings tab, which the backend named. What is still open is that Settings itself has no slot in the fixed app menu (D-40), and nothing says where the status — code, response time, up / down / SSL error — is shown. Same family as D-40, D-43, D-45 and D-46 |
| — | Is there an uptime history, or only the current status? 14.6 lists what each check records, and 14.7 alerts on changes, but nothing says whether the user can see past checks Open question — so this spec shows the current status only and does not invent a history screen |
| — | Who closes the Slack channel when the pack ends? 14.8 says support handles it, which means Central cannot tell the user what happened to it Open question |
| — | Does the screen have to show both prices? 14.2 now says the discount applies only when paying from credit, so the credit route and the card route cost different amounts. Whether the backend expects both to be shown before the choice is not stated — this spec says show both, because the alternative is a surprise on the receipt Open question |