SGEN reliability and uptime explained
How to think about SGEN reliability and uptime
Reliability matters most when something is wrong. Most of the time SGEN runs invisibly — pages load, forms submit, analytics tick over. This page explains what to expect when reliability becomes a question, how to read the platform's status signals, and what to do if your site has a problem that might be platform-side.
The plain version: the platform aims for very high availability. Issues happen rarely. When they do, the status page reports them in real time, the platform team works the fix, and the changelog records the post-incident review. Your role is mostly to know where to look and how to interpret what you see.
This guide also covers the small set of habits that turn reliability from a worry into background music — checking the status page when something looks off, knowing what counts as a platform issue vs a site-side issue, and how to communicate to your own customers during an unusual moment.
What is this for?
Customers ask several reliability questions:
- What uptime should I expect from SGEN? Is there an explicit target?
- What does it mean when the status page shows an incident? How serious?
- How do I know if a problem is on my side or the platform's side? What is the test?
- What should I tell my own customers during a platform incident? How do I communicate?
- Is there a service-level agreement? Are there guarantees?
- What happens after an incident? Post-mortem? Credits?
- How do reliability practices change as plan tier increases? Different commitments at different levels.
The right answers depend on your business. A small operator may need a quick check-and-trust approach. A mission-critical operator may need formal monitoring on top of the platform's signals.
The platform itself runs a set of reliability practices that you do not need to manage — capacity management, automated health checks, on-call coverage, regular rehearsals. Your interface is mainly the status page, the changelog, and the support team for anything unusual.
The reliability conversation also intersects with your own customers' expectations. When your customers depend on your site, your reliability is a function of both the platform's reliability and your own operational discipline. This guide focuses on the platform-facing half; your operational discipline is the other half.
Good use cases
Reading this page beforehand sets expectations: keep the status page open, know which signals matter, know who to contact if something looks off.
Reliability is part of the product. Understand what the platform delivers and what you should monitor on your own side.
Reliability practices are part of the comparison. The public status page and the changelog give a track record.
When a client asks "what if something goes wrong?" the agency can point at the status page, the changelog, and this guide.
The status page during the moment is the answer. If nothing was reported there, the issue was likely client-side or a brief blip not affecting other customers.
Knowing the platform's reliability posture helps the team set their own SLA promises to their stakeholders.
Reliability questions come up regularly in customer conversations. Having the answers ready prevents stalling.
Reliability practices inform business-continuity assessments. The platform's track record is part of the input.
What NOT to use this for
SGEN reports platform-wide health. If your business depends on a specific page being up at a specific moment, run your own uptime check against that page in addition to watching the platform's signals.
Very high reliability is not 100% reliability. Plan for the occasional brief incident.
The status page reports incidents as they happen. It does not predict future incidents.
Reliability is about staying up. Backups are about recovering when something goes wrong despite the up-keeping. Both matter; they cover different cases.
During an incident, your customers care about your business, not the platform. Have a way to communicate to your customers ("we are experiencing a brief issue, working on it") that does not depend on the platform.
Reading this page is part of the diligence; the public status page history and the platform's track record are the rest.
Third-party services you integrate with have their own reliability posture. The platform's reliability does not extend to those.
How this connects to other features
The canonical real-time signal of platform health. Bookmark it.
Post-incident reviews appear in the changelog after resolution. Read for the "what happened and why" detail.
Records actions you and your team take. During an incident, the audit log can confirm what was happening on your account.
Per-site backups are independent of platform reliability. Restore from backup is your tool for "we need to roll back" cases.
During an unusual moment, support is the right contact. They have visibility into what the platform team is seeing.
During and after an incident, your own analytics show what your site experienced. Drop in traffic during the incident window is normal; recovery patterns afterward are worth a glance.
If forms were submitted during an incident, the platform's recovery process backfills them where possible. Check the form submission inbox after recovery.
Before you start
A short checklist:
- Bookmark the status page. Pin it in your browser's bookmark bar.
- Sign up for status page notifications. Email, SMS, or webhook delivery on the status page itself. You hear about incidents the moment they are reported.
- Pick an internal channel for incident discussion. A Slack channel, a shared email alias, anywhere your team can coordinate without going through SGEN.
- Draft an incident communication template. A short message you can send to your customers if a platform incident affects them. Write it once, use it as needed.
- Know your support contact path. Sign-in to support, email address, or in-product chat — whichever your plan supports.
- Document your monitoring posture. If you run additional uptime checks on your own pages, document where they live and who watches them.
- Decide your team's escalation path. Who calls who if an incident affects a critical launch? Write it down.
Where to go
The key locations:
- Status page. Public, real-time platform health.
- Status notifications. Subscribe at the status page itself for email or webhook delivery.
- Account → Notifications → Incident Email. Some plan tiers offer account-level incident notifications that include any extra context relevant to your account.
- Changelog → Incidents. Filter the changelog to incident post-mortems for a deeper read after resolution.
- Support → Open ticket. The right path for anything that looks site-specific or unusual.
The status page is the canonical signal — everything else is supporting context. Pin it at the top of your bookmarks. Many ops teams put it on a wall display alongside other monitoring screens.
Steps — Stay informed and respond well
1. Subscribe to status page notifications
Open the status page in your browser and click Subscribe. Enter your team's shared ops email or your personal email. Confirm. From this point, you receive email notifications when the platform reports an incident.
Some plans offer SMS or webhook delivery in addition to email. For mission-critical operations, SMS or webhook (into your monitoring system) ensures you hear about incidents on a different channel than the one that might also be affected.
2. Know what the status levels mean
The status page uses a small set of levels:
- Operational. Everything normal. No reported issues.
- Degraded. Something is slower than usual but the platform is still functional. Many incidents start at this level.
- Partial outage. Some functionality is unavailable. A specific area (e.g., form submissions) may not be working; the rest of the platform is fine.
- Major outage. Significant functionality is unavailable. Rare.
Learn what your team's threshold for action is. Operational and Degraded often do not require any action on your side. Partial and Major outages might.
3. Set your team's incident channel
When the platform reports an incident, your team needs a place to talk about it. A pre-existing Slack channel works well — "platform-incidents" or similar. Drop a link to the status page incident and coordinate from there.
The channel keeps incident response from spilling into other team conversations and gives you a written record of what your team decided during the incident.
4. Communicate to your own customers
For incidents that affect your customers, send a brief, factual update. A two-sentence template works:
We are experiencing a brief issue affecting some functionality on our site. We are working on it; updates here as we have them.
Avoid speculating about cause. Avoid promising specific recovery times unless the platform has stated them. The job is to acknowledge.
After recovery, send a brief follow-up:
The issue is now resolved. Thanks for your patience.
5. Check your forms after recovery
When forms-related incidents resolve, check your form submission inbox for the incident window. The platform's recovery process typically backfills submissions captured during the incident; verify they are there. If submissions are missing, file a support ticket with the time range.
6. Read the post-incident review
After resolution, the platform publishes a post-incident review in the changelog within a few days. The review explains what happened, what was affected, and what changes are being made. Read it; it sets expectations for whether the same issue could recur.
7. Run your own uptime check (if mission-critical)
For sites where reliability matters more than the platform's baseline, run an external uptime check against your most-important page. Services that do this run a low monthly cost and report independently of the platform's status. Two signals (platform status + your own check) catch a wider range of issues.
8. Review reliability with your team quarterly
Quarterly, look at the platform's incident history for the last 90 days. Were there incidents that affected you? Did your communication plan work? Was your monitoring sufficient? Adjust as needed.
9. Update your incident communication template
After every incident your team experiences, refine the template based on what worked or did not. The next incident finds you better prepared.
What success looks like
A team handling reliability well feels like: For a small operator: subscribe + watch the status page + use the support channel. Done. For a customer-facing business: add the customer-communication template and the brief follow-up message. Pre-draft so you do not write under pressure. For an agency: the playbook covers the agency's response and the client communication path. Clients hear from the agency, not from the status page directly. For a mission-critical operator: external monitoring, formal escalation paths, and quarterly reliability reviews are worth the effort.
- The status page is bookmarked and notifications are on. The team hears about issues from the platform, not from customers.
- During an incident, the team has a clear coordination channel. People are not bouncing between Slack DMs.
- Customer-facing communication goes out within 15 minutes of a customer-affecting incident.
- After resolution, the team reads the post-incident review and adjusts.
- Quarterly reliability reviews surface anything worth changing.
- Mission-critical sites have a second monitoring signal (external uptime check).
What to do if it does not work
Less-obvious cases:
Likely a site-specific issue or local browser/network issue. Try another browser, another network, or another device. If still broken, file a support ticket.
Some incidents affect a subset of customers or specific features. Read the incident detail; it usually names what is affected.
Confirm the subscription is active on the status page. Check spam. Re-subscribe if needed.
The status page updates as the platform team has information. Sometimes an incident enters a quiet investigation phase between updates. Check support for additional context.
Check the status page first. If an incident is reported there, send your customer communication. If not, file a support ticket — your customers may be seeing something the platform is investigating.
Reviews cover the platform-level cause and customer-level impact in aggregate. If your specific impact was unusual, contact support with details.
SLA terms depend on plan tier. Contact your account contact to discuss SLA options.
Worked example — Acme Coffee handles a 40-minute incident
In March 2026 the platform reported a 40-minute incident affecting email delivery from forms. Acme Coffee's operations team responded:
- Heard about the incident from their status page notification. Email arrived two minutes after the status page report.
- Confirmed the issue affected them. Their contact form was capturing submissions, but the confirmation emails to senders were delayed.
- Posted in their team channel. Two-sentence note: "Form emails delayed per status page, working a customer comm if needed."
- Drafted a brief customer note. Did not send yet — wanted to see how long the incident would last.
- At 30 minutes in, sent the customer note to anyone who had submitted a form that day. "Your message came through; our confirmation email is delayed because of a brief platform issue. We will respond to your message normally."
- At 42 minutes, the incident resolved. Confirmation emails delivered for backlogged submissions.
- Read the post-incident review when it appeared in the changelog two days later. Confirmed the issue was platform-side, fixed, and steps were being taken to prevent recurrence.
Total team time spent on the incident: about 20 minutes. Customer impact: minimized because of clear communication.
Worked example — Acme Studio prepares for a client launch
An agency client was launching a major product on a specific Tuesday. The agency operations manager prepared for reliability ahead of the launch:
- Confirmed the status page was bookmarked across the team. Three people on the launch team had it.
- Reviewed the last 90 days of platform incidents. No major issues in the relevant features. Reasonable baseline.
- Set up an external uptime check on the client's launch landing page. Independent signal in case anything site-specific went wrong.
- Pre-drafted two customer-communication templates. One for "everything is fine" launch update, one for "we are working on a brief issue" if needed.
- Briefed the client. Walked them through the platform's status page and the agency's incident response process.
The launch went smoothly. The preparation was insurance — used only if needed. Most launches do not need it. But when launches do go sideways, the prepared team responds in minutes instead of scrambling.
Notes on the reliability model
A few details worth knowing:
Status page is the canonical signal. The platform team updates the status page as fast as humanly possible after detecting an issue. Other channels (support, social media, customer chats) follow. The status page is the source of truth.
Some issues affect subsets of customers. Not every incident affects every account. The status page incident detail names the affected scope (e.g., "form submissions in some regions") so you can tell whether you are likely affected.
The platform separates customer data from platform state. Reliability issues affect availability, not data integrity. Customer data persists through incidents. Backups remain intact.
Recovery processes are designed for graceful catch-up. When an incident resolves, queued work (form submissions, scheduled posts, analytics events) typically processes through. Check after recovery to confirm.
Post-incident reviews are public for major incidents. Smaller incidents may not get a public review but are tracked internally. If you want detail on a smaller incident that affected you, contact support.
Reliability is a team responsibility. The platform team manages platform reliability. Your team manages your site's reliability — content correctness, integration health, custom code quality. Both matter; both are independent.
SLA terms scale with plan tier. Higher-tier plans typically include more explicit SLA language and faster support response. Check your plan's documentation for specifics.
Building reliability into your own operations
Beyond watching the platform's signals, a few practices strengthen your overall site reliability:
Document your site's "critical path." Which pages and features matter most to your business? If those are working, you are operationally fine. List them; revisit yearly.
Test your communication path regularly. Once a quarter, walk through your incident communication template with the team responsible. Confirm everyone knows where to find it and how to send it.
Maintain a backup of recent content. Beyond platform backups, periodic exports of your most-important content to your own storage provides extra resilience.
Train at least two team members on incident response. Single points of failure on the human side are as risky as on the platform side.
Keep your customer communication channels healthy. Email lists, social channels, status page on your own site (if you maintain one) — make sure each is operational so you can use them during an incident.
Practice once a year. A simple tabletop exercise — "if the platform had an incident today during our biggest sale, what would we do?" — surfaces gaps quickly.
Treat reliability as a steady investment, not a one-time setup. The conditions of your business change; what was sufficient a year ago may not match this year's traffic or stakes.
Review your dependencies. Beyond the platform, you depend on email providers, domain registrars, third-party scripts. Each is a reliability link. Review them yearly.
Match monitoring to your risk profile. A side-project blog and a high-volume ecommerce site have different monitoring needs. Choose tools and cadence that match.
Common questions
What is SGEN's uptime target? The platform targets very high availability. Specific SLA percentages depend on plan tier; check your plan documentation or contact your account contact.
Where is the status page? The status page link is in your account dashboard footer and in support communications. Bookmark it.
Do incidents always show on the status page? Anything affecting customer-visible behaviour shows. Internal-only issues that customers do not experience may not.
How fast does the status page update? The platform team aims to post a status update within 15 minutes of detecting a customer-affecting issue. Most updates land much faster.
Will I get credited for downtime? Credit policies depend on plan tier and SLA terms. Check your plan's documentation.
Can I see historical incident data? The status page shows incident history. The changelog also has post-incident reviews for major incidents.
Should I run my own uptime check? For mission-critical sites, yes. For most operators, the platform's signal is enough.
What is the difference between Degraded and Outage on the status page? Degraded means slow but functional. Outage means a piece of functionality is unavailable. Two different levels of impact.
Does the platform run regular incident rehearsals? Yes. The platform team practices incident response regularly to keep the playbook fresh.
Can I be added to a higher-tier incident notification list? Some plans include priority notification paths. Check your plan or contact your account contact.
What is the platform's on-call coverage? The platform maintains 24-7 on-call coverage. Incidents at any hour are responded to.
Can I escalate an issue I think is critical? Yes — contact support and flag the urgency. For paid plans with priority support, escalation paths are part of the plan.
Does the platform offer a private status page for my customers? Some plan tiers offer a customer-facing status page you can embed in your site. Check your plan documentation.
How do I find out about scheduled maintenance? Scheduled maintenance, when it happens, is announced on the status page and via subscription email at least a few days in advance.
Related reading
Reliability is mostly a quiet background. Pay attention when the status page lights up, communicate to your own customers, read the post-incident review, and keep moving. The platform handles the technical recovery; your job is the human side of the response.
How SGEN handles platform updates — the cadence and quality of platform changes.
SGEN site performance explained — speed for visitors.
SGEN data security and privacy — how your data is protected.
SGEN backups and disaster recovery — your safety net for recovery scenarios.