Outages, evidence and planned maintenance

Read an outage as an evidence-based finding

Cenovel records conditions it can observe through network management and server management controllers. An outage may identify lost contact, a missing stack member, a failed part or a capacity risk. These are useful operational signals, but they do not all mean users have lost service. A responding switch does not prove that traffic is forwarding, and a responding server controller does not prove that the operating system or an application is healthy.

Check the cause, affected device or part, observation time and supporting detail before deciding the response. Critical and Warning are triage priorities. They are not measurements of how many people are affected. Whether a site is a priority site comes from its site type, not from its name or notes. In Settings › Locations › Site types, an Administrator EX sets each type's outage urgency to Normal or Priority. A network outage that monitoring opens at a site whose type is Priority is raised to Critical, its alert is marked URGENT, and the alert names the site type as a priority facility.

Prepare the record and the management read

• Record equipment at the correct site and closet, with a usable management address. Keep stack membership and access-point connections accurate: several detectors compare current evidence with those records.
• Configure the applicable credential, trusted SSH key or server certificate, and permitted management networks. A successful login does not guarantee that every hardware table or command is supported or complete.
• Network lost-contact detection requires a successful monitoring baseline. Cenovel reports a switch as not answering only after it has read that switch successfully at least once; a retained discovery identity alone is insufficient. Server-controller lost-contact detection does not have that same prior-answer requirement.
• Viewing current outages, viewing history and downloading evidence are separately permissioned. Scheduling, editing or canceling maintenance requires current-outage edit permission and permission to write.

Network detectors

The following are the implemented causes and their default priorities. A single eligible assessment can open a condition; there is no common requirement for three failed checks or another fixed failure count. A detector runs only when the read supplies the evidence it needs.

Scroll the table sideways to read all columns.

Server-controller detectors

These five causes use supported Redfish hardware readings. Controller health describes hardware and reported conditions. It does not test a hosted application, user login or operating-system service.

Scroll the table sideways to read all columns.

Review and confirm recovery

For example, a switch may answer while its fan command fails. Its lost-contact incident can resolve while its earlier fan incident remains open. Similarly, a controller may return three healthy fans and fail to read the fourth: the missing fourth fan is not automatically declared repaired.

Incident times are detection and confirmation times, not exact physical failure times. Outage duration excludes time held for management-network uncertainty. Site downtime merges overlapping incident periods instead of adding every device's minutes as if they were separate periods of site-wide disruption; it still does not measure actual user impact.

When a fresh successful read clears a switch or access-point lost-contact incident, its recovery entry can include the complete current uptime value and its source. The entry keeps a physical restart verdict unknown. A short uptime alone does not prove a reboot; a long uptime does not prove that only the network path failed. Stored fallback readings and unrelated hardware recoveries do not receive this contact-recovery annotation.

1. Open the incident detail and compare the named device, member or part with the site record. Inspect the underlying failure and latest evidence rather than relying on the title alone.
2. Check whether the required portion of the read completed. Positive fault evidence can still be useful in a partial read; missing data cannot be treated as a healthy replacement for an earlier fault.
3. Check reported user impact separately. For an uplink incident, confirm the traffic path and redundancy. For a server incident, check the application through its normal service checks.
4. After repair, obtain the relevant supported reading and verify the incident's recovery entry. A general successful connection is insufficient for an unread failed fan, supply or storage condition.
5. Use history and available evidence downloads to preserve the timeline. If equipment was removed from Cenovel, distinguish the subject-removed closure from restored service. When a unit is swapped out with Replace, the old unit's open outages close as Replaced by the new serial on that date; for a stack member, only that member's outages close. That records the swap, not a repair of the old unit.

When Cenovel may have lost its own management path

Cenovel raises a management-network condition when at least two distinct addresses have transport-silence evidence across the current check and the recent 15-minute window, at least one was silent in the current check, and no genuine answer appears in either set. The failures need not all have occurred at exactly the same instant.

A successful read or explicit sign-in refusal counts as an answer for this condition. A changed key, certificate response, closed port or negotiation failure is treated as ambiguous for deciding whether the wider management path recovered. One isolated silent address cannot establish this shared condition.

While the condition is open, new switch and access-point lost-contact outages are withheld. Existing incidents of those two kinds are neither confirmed nor resolved, and their duration clocks pause. Hardware and server-controller incidents are outside this particular hold. A genuine answer releases the hold; a return within 15 minutes can remain the same management-network episode.

If Cenovel could not use its own stored credential and therefore never contacted a device, it reports a separate console-credential problem. Correct access through Monitoring rather than treating this as evidence that the device failed.

Schedule maintenance and keep the history

Maintenance suppresses alerts while monitoring continues and incidents remain recorded. Covered outages are excluded from ordinary current-outage lists, Today, actionable incident summaries, morning-report incident sections and ordinary outage totals. Moving an incident into maintenance is not reported as a recovery. The site's outage list retains covered records with maintenance context, while its outage statistics exclude them.

An incident still open when coverage ends becomes eligible for ordinary visibility and alerts again. An incident resolved while covered retains its maintenance classification in history. Ordinary evidence exports exclude maintenance incidents, so a site's visible history and an ordinary export can contain different rows. Maintenance is not a promise that a fault was repaired or that all of its duration will be subtracted from a later unsuppressed incident.

Scope matters. A site window covers everything monitored at that site, including devices added during the window. A closet window covers the switches and servers in that closet and the access points behind those switches; other closets at the same site still alert. A switch window covers that switch or stack, not access points behind it that fail on their own. An access-point window covers only that access point. A server or address window covers the device at that address. An access point that Juniper Mist reports is offered as Juniper Mist's disconnected report, and its window quiets that report. Ended and canceled windows cannot be edited.

A future window quiets nothing until it starts. When a window ends or is canceled while an outage it covered is still open, the outage returns to Outages and its alert is sent once, even if several parts of Cenovel notice the end. That includes an alert that was waiting to be sent when the window began. An alert already delivered before the window is not sent again, and an outage that cleared during the window sends nothing.

1. Choose what the work affects. Only things Cenovel monitors are offered, each once: a site, a closet, a switch or stack, an access point, a server, or a polled address. Inventory records without a management address raise no alerts, so they are not listed. Read the line under the choice: it says what the window will quiet and what will still alert.
2. Enter a readable reason, start and end times, and the intended time zone. Add a work reference when useful. The end must follow the start, and a single window cannot exceed 180 days.
3. Confirm the scheduled window before starting work. It becomes active at its start time and stops applying at its end time. Edit or cancel a current window when plans change; cancellation requires a reason.
4. Use the site's outage history to review incidents observed during the work. After maintenance ends, inspect any still-open conditions and obtain recovery evidence.

Interpret protocol evidence conservatively

The official Interfaces MIB describes an interface's operational state, not an end-to-end application's availability. Missing neighbour advertisements can also reflect the neighbour protocol or its configuration. Cenovel therefore combines a recorded neighbour, complete reads and a down operational port for its uplink rule.

SNMP system uptime measures time since the management portion was initialized. Its TimeTicks representation wraps after approximately 497 days. A decrease can suggest a management-agent restart or a wrap rather than a whole-device reboot. Corroborate the event with device logs when the distinction matters.

The ENTITY state standard allows enabled to mean partially or fully operable; it does not prove redundant power. Redfish likewise distinguishes a component's health from the health of the containing system. A failed redundant supply can need attention while the system continues operating. Use the vendor's reported detail and actual service checks to establish impact.