The Status Page webhook allows you to receive real-time notifications whenever there is a change in service status or an incident update. These webhooks provide essential information about incidents, components, and their status changes. 

Here’s how you can set up and use the webhook:

1. Visit Freshstatus Homepage:

   • Go to our Freshstatus homepage at https://gridlines.freshstatus.io/ 

2. Select Webhook:

   • Click the Subscribe button located in the top-right panel and Choose Webhook from the available options.

3. Provide Details:

   • Enter your Email address. (As an option to receive email notifications in case the endpoint fails)

   • Specify the URL where you want the webhooks to be sent.

• If required, provide any necessary Webhook credentials.

4. Subscribe to Webhook:

   • Click on the Next button and then Choose the services you want to be notified about from the list of services.

   • Click on Subscribe.

5. Verify Your Email Address:

   • One last step! Please verify your email address by clicking on the Verify my email link you received on an email from updates@freshstatus.io..

That’s it! You’re all set to receive real-time notifications about service status changes via the Freshstatus webhook.

Interpreting Status Page Webhook Responses

When integrating with our status page webhook, it's essential to understand how to interpret the JSON responses, enabling you to effectively manage your services during incidents. Here’s how you can interpret the information according to your use cases:

1. Identify the Affected Service:

   1. Examine the event_data.affected_services field, It shows the Impacted service.

   2. Verify if any of the listed services match those used in your workflow. Alternatively, You can configure your webhook for specific services. By doing so

      1. You’ll receive targeted notifications for only the relevant services.

      2. You can track the status of a single/multiple services using a single webhook.

2. Assess the Impact:

   1. Review the event_data.title field.

   2. Look for the status information indicating the impact, such as :

      1. Operational: Service is functioning normally.

      2. Degraded: Service is experiencing performance issues.

      3. Partial Outage: Service is partially available but with limitations.

      4. Major Outage: Service is unavailable or severely impacted.

      5. Maintenance: Service is undergoing planned maintenance.

   3. The status provides insights into the severity of the issue based on the API’s success rate.

3. Monitor and Adjust Workflow:

   1. Continuously monitor the event_type and Incident_status fields.

   2. event_type indicates the event type (e.g., incident, maintenance).

   3. Incident_status reflects the current incident status (e.g., Open, Closed).

4. Adapt Workflow During Incidents:

   1. If an incident is ongoing (status is not “Closed”), consider adjusting your workflow.

   2. Modify your workflow to minimize the impact of the incident on your operations.This may involve disabling checks or functionalities dependent on the affected service.

5. Resume Normal Operations:

   1. Once the incident is resolved (status changes to “Closed”), resume regular operations in your workflow.

Example Response Breakdown : 

JSON

"event_type": "INCIDENT_CREATED",

"event_data": {

  "title": "Fetch Employment History By UAN Services - MAJOR_OUTAGE",

  "affected_services": "Fetch Employment History By UAN",

  "description": "The government source for Fetch Employment History By UAN service is currently undergoing maintenance. The service is still partially available, but it is functioning at a significantly reduced capacity. We will continue to monitor the situation and inform you of any change in service levels.",

  "status": "Open"

}

In the above example:

• The event type is "INCIDENT_CREATED," indicating the creation of a new incident.

• The affected service is "Fetch Employment History By UAN."

• The description provides the details of the issue with respect to the affected service.

• The incident is now "Open," signifying that the service is still affected.

Below is a guide to help you decipher the information provided in the response:

1. Event Types:

• The "event_type" field indicates the type of event triggering the webhook. For instance, an "INCIDENT_UPDATED" event signifies an update related to an existing incident or “INCIDENT_CREATED” event signifies the change in a service.

2. Event Details:

• Look for the "title" and "description" fields in the “event_data” to understand the nature and severity of the incident. 

• The "title" provides a brief description, while the "description" offers additional context, including the cause and impact.

• To find the name of the affected service, refer to the “affected_services” field in the JSON response under “event_data”.

3. Incident Status:

• The "Incident_status" field indicates the current status of the incident. If it's "Closed," the incident has been resolved. Otherwise, if it's "Open" or "Ongoing," the incident is still active.